docs: Add secure collaboration learning path#29386
Conversation
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
|
Hey there, we've marked this pull request as stale because there's no recent activity on it. This label helps us identify PRs that might need updates (or to be closed out by our team if no longer relevant). |
|
PCX triage note — PCX team pinged the assigned reviewer on 2026-04-20. Waiting for review. |
| title: Account structure | ||
| pcx_content_type: overview | ||
| sidebar: | ||
| order: 1 |
There was a problem hiding this comment.
I would change this to 2 because it's showing up before the "Setting up CF for secure collaboration" in the nav
| order: 2 | ||
| --- | ||
|
|
||
| ## Why this matters |
There was a problem hiding this comment.
I would remove this header and skip straight to the intro sentence on line 10.
| order: 4 | ||
| --- | ||
|
|
||
| ## Why this matters |
| order: 2 | ||
| --- | ||
|
|
||
| ## Why this matters |
| order: 3 | ||
| --- | ||
|
|
||
| ## Why this matters |
…t-compliance/audit-logs.mdx Co-authored-by: Denise Peña <75506267+dcpena@users.noreply.github.com>
…t-compliance/alerts-notifications.mdx Co-authored-by: Denise Peña <75506267+dcpena@users.noreply.github.com>
…x.mdx Co-authored-by: Denise Peña <75506267+dcpena@users.noreply.github.com>
…unt-structure/account-hierarchy.mdx Co-authored-by: Denise Peña <75506267+dcpena@users.noreply.github.com>
…ork-security-products/waf-ddos.mdx Co-authored-by: Denise Peña <75506267+dcpena@users.noreply.github.com>
…unt-structure/account-hierarchy.mdx Co-authored-by: Denise Peña <75506267+dcpena@users.noreply.github.com>
|
CI run failed: build logs |
Broken LinksFound 1 broken link(s) across 1 file(s).
|
|
Hey there, we've marked this pull request as stale because there's no recent activity on it. This label helps us identify PRs that might need updates (or to be closed out by our team if no longer relevant). |
|
@rianvdm do you mind having a look at this one? Stalled out in review phase. Thanks! |
|
@jhutchings1 Yes, will review this today. |
rianvdm
left a comment
There was a problem hiding this comment.
Added a few comments but there are also some structural issues. For instance, the style guide requires description: whenever pcx_content_type is set. All 27 pages set pcx_content_type and none have a description.
Recommend a separate /review-branch-code command from inside the cloudflare docs repo, in addition to resolving all comments.
| - [Get started with Zero Trust](/cloudflare-one/setup/) | ||
| - [Connect to Cloudflare Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/) | ||
| - [Configure an identity provider](/cloudflare-one/integrations/identity-providers/) | ||
| - [Replace your VPN learning path](/learning-paths/replace-vpn/) — a full walkthrough for teams migrating from VPN |
There was a problem hiding this comment.
Build CI is complaining about this link. It redirects in prod but we should change it to /learning-paths/replace-vpn/concepts/ to pass validation
|
|
||
| ## Recommendations | ||
|
|
||
| Enable the Cloudflare Managed Ruleset and configure DDoS protection to "high" sensitivity for all public-facing zones. These are the two highest-value, lowest-effort security improvements available in the WAF, and they should be on by default for every production zone. |
There was a problem hiding this comment.
High is the default and it can only be lowered according to docs, so maybe: "Turn on the Cloudflare Managed Ruleset and confirm DDoS protection is at the default "High" sensitivity for all public-facing zones."?
| ## Key considerations | ||
|
|
||
| - **The Cloudflare Managed Ruleset covers the OWASP Top 10 and known CVEs.** It is updated automatically as new threats emerge. Enabling it takes one click and requires no ongoing maintenance. The default action is to block, but you can set rules to log-only first if you want to observe what it would block before committing. | ||
| - **DDoS Override rules let you configure sensitivity and action per zone.** The default DDoS protection is always on and cannot be turned off, but you can tune it. For most production sites, increasing sensitivity to "high" and setting the action to "block" (rather than "challenge") is appropriate. Legitimate traffic patterns rarely trigger high-sensitivity DDoS rules. |
There was a problem hiding this comment.
Same comment here, default is "High." Suggestion:
"The default sensitivity is High and the default action is Block — leave both as-is for most production sites. Lower the sensitivity only if you observe false positives on legitimate traffic."
|
|
||
| ## Key considerations | ||
|
|
||
| - **The Cloudflare Managed Ruleset covers the OWASP Top 10 and known CVEs.** It is updated automatically as new threats emerge. Enabling it takes one click and requires no ongoing maintenance. The default action is to block, but you can set rules to log-only first if you want to observe what it would block before committing. |
There was a problem hiding this comment.
OWASP is a different different rules (docs). So maybe "The Cloudflare Managed Ruleset covers common attack techniques and known CVEs." And add "For OWASP Top 10 coverage specifically, also turn on the Cloudflare OWASP Core Ruleset."
| | Team member | Recommended roles | | ||
| |---|---| | ||
| | Senior engineer or tech lead | `Administrator` (account-scoped, if truly needed) | | ||
| | Developer working on a specific domain | `DNS`, `Workers Editor` — scoped to that zone | |
There was a problem hiding this comment.
Per Roles, Workers Editor grants access to the Workers Playground only — it does not let a member edit deployed Workers. The role for developer-platform editing is Workers Platform Admin).
| title: Members, roles, and permissions | ||
| pcx_content_type: overview | ||
| sidebar: | ||
| order: 2 |
There was a problem hiding this comment.
Some renumbering needed, there is already a number 2.
|
|
||
| ## Why this matters | ||
|
|
||
| R2 buckets are private by default, but it is easy to accidentally make one public. A misconfigured public bucket can expose data to the entire internet. Even when public access is intentional, it needs to be controlled. |
|
|
||
| ## Why this matters | ||
|
|
||
| DNS is the phonebook of the internet. Attackers who can tamper with your DNS records can redirect your users, intercept traffic, and issue fraudulent TLS certificates. Two of the most common DNS-based attacks, DNS cache poisoning and subdomain takeover, are preventable with straightforward configuration. |
| order: 5 | ||
| --- | ||
|
|
||
| Securing your account and developer resources covers the inside of your Cloudflare configuration. This module covers the products that protect what you expose to the internet: your domains, applications, and team members' access to internal tools. |
|
|
||
| ### Connect your application with Cloudflare Tunnel | ||
|
|
||
| For self-hosted applications, Cloudflare Tunnel (`cloudflared`) is how your origin connects to Cloudflare's network without opening inbound firewall ports. The `cloudflared` daemon runs in your infrastructure and creates outbound-only connections to Cloudflare's edge. You can configure your firewall to block all inbound traffic and allow only these outbound connections, so your origin is never directly reachable from the internet. |
|
Hey there, we've marked this pull request as stale because there's no recent activity on it. This label helps us identify PRs that might need updates (or to be closed out by our team if no longer relevant). |
Summary
This new learning path documents a number of security best practices for customers in terms of setting up an account, inviting collaborators, creating API tokens, creating developer products, and finally securing them behind Zero Trust. This is intended to be high level and guide folks to more specific docs that already exist.
@AdamBouhmad @irvinebroque @asamborski @dcpena would love to get your thoughts on this.
Screenshots (optional)
Documentation checklist