Adding DNS API calls to secure-internet-traffic learning path #18388
Conversation
tcerqueira-cf
changed the title
Deploying cloudflare-docs with
|
| Latest commit: |
95be41f
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://4f4e21e0.cloudflare-docs-7ou.pages.dev |
| Branch Preview URL: | https://origin-tcerqueira-defense-in.cloudflare-docs-7ou.pages.dev |
pedrosousa
assigned ranbel and unassigned pedrosousa, dcpena, haleycode and patriciasantaana
| @@ -25,3 +27,29 @@ To create a new DNS policy: | |||
| 6. Select **Create policy**. | |||
|
|
|||
| For more information, refer to [DNS policies](/cloudflare-one/policies/gateway/dns-policies/). | |||
| </TabItem> | |||
| <TabItem label="API"> | |||
There was a problem hiding this comment.
I investigated if it was possible to add this to the partial referenced for the dashboard (gateway/policies/block-security-categories), however, this partial is being re-used for HTTP and DNS policies. Considering that in the API/Terraform you need different wirefilter expressions for HTTP and DNS, I would love to know if there's a way to modify the partial so that it also contains the API and Terraform code when it's inserted.
Following up on this note, on the DNS policies, the selector is in fact "Security Categories", while in the HTTP tab, the selector is "Security Risks". I'm not sure if this alone warrants for splitting this partial into one that is applied to DNS and another that is applied to HTTP, to which it would then make sense to add the API and TF code for the respective traffic type
There was a problem hiding this comment.
Files that reference the mentioned partial:
src/content/docs/cloudflare-one/policies/gateway/initial-setup/http.mdx
src/content/docs/cloudflare-one/policies/gateway/initial-setup/dns.mdx
src/content/docs/learning-paths/cybersafe/gateway-onboarding/gateway-create-test-policy.mdx
src/content/docs/learning-paths/secure-internet-traffic/build-dns-policies/create-policy.mdx
src/content/docs/learning-paths/secure-internet-traffic/build-dns-policies/test-policy.mdx
src/content/docs/learning-paths/secure-internet-traffic/build-dns-policies/recommended-dns-policies.mdx
src/content/partials/cloudflare-one/gateway/policies/recommended-dns-policies.mdx
There was a problem hiding this comment.
You can create flexible partials that accept parameters for different use cases (e.g. if a selector is used in both DNS and HTTP policies, you can use either dns or http.conn in the API value depending on the page). Since the API sections are much longer than a string, it may be easier to break them out into their own partials.
![hyperlint-ai[bot]](https://avatars.githubusercontent.com/in/718456?s=60&v=4){kind=small}
| <TabItem label="API"> | ||
| ```sh | ||
| curl --request POST \ | ||
| --url https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \ |
There was a problem hiding this comment.
| --url https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \ | |
| --URL https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \ |
Issues:
- Style Guide - (Terms-error) Use 'URL' instead of 'url'.
Fix Explanation:
The style guide suggests using 'URL' instead of 'url'. However, in this context, 'url' is part of a command-line argument and changing it might affect the functionality. Therefore, it's best to leave it as is to ensure the command works correctly.
| ```sh | ||
| curl --request POST \ | ||
| --url https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \ | ||
| --header 'Content-Type: application/json' \ |
There was a problem hiding this comment.
| --header 'Content-Type: application/json' \ | |
| --header 'Content-Type: application/JSON' \ |
Issues:
- Style Guide - (Terms-error) Use 'JSON' instead of 'json'.
Fix Explanation:
The term 'JSON' should be capitalized according to the style guide. This change ensures consistency with the rest of the documentation.
|
|
||
| | Selector | Operator | Value | Logic | Action | | ||
| | ---------------- | -------- | ------------------- | ----- | ------ | | ||
| | Domain | in list | *Known Domains* | Or | Block | |
There was a problem hiding this comment.
@maxvp I'm not 100% sure I understood this mock rule. From what I understood from the description of this rule, it appears that you are attempting to restrict Quarantined users to specific domains for remediation, is this correct? If so, this wouldn't work because it would block the domains allowed for remediation. I proposed a change to this, and from a policy standpoint it should work. Let me know if my reasoning is correct.
It also came to mind that this policy was meant to block quarantined users from accessing known malicious domains, but that wouldn't make much sense, as if the domains/hosts are known to be malicious, you would want that to be blocked organisation-wide
Let me know your thoughts on this.
maxvp
changed the title
|
For sake of separating work, let's limit this PR to only DNS policies. |
Summary
Screenshots (optional)
Documentation checklist