diff --git a/public/_redirects b/public/_redirects index 79ea5e5fd0b565..302b51524fb1e9 100644 --- a/public/_redirects +++ b/public/_redirects @@ -79,7 +79,7 @@ /access/service-auth/mtls/ /cloudflare-one/identity/devices/access-integrations/mutual-tls-authentication/ 301 /access/service-auth/service-token/ /cloudflare-one/identity/service-tokens/ 301 /access/setting-up-access/ /cloudflare-one/identity/ 301 -/access/setting-up-access/access-groups/ /cloudflare-one/identity/users/groups/ 301 +/access/setting-up-access/access-groups/ /cloudflare-one/policies/access/groups/ 301 /access/setting-up-access/audit-logs/ /cloudflare-one/insights/ 301 /access/setting-up-access/configuring-access-policies/ /cloudflare-one/policies/access/policy-management/ 301 /access/setting-up-access/validate-jwt-tokens/ /cloudflare-one/identity/authorization-cookie/validating-json/ 301 @@ -1634,6 +1634,7 @@ /cloudflare-one/api-terraform/gateway-api-examples/dns-policy/ /cloudflare-one/policies/gateway/dns-policies/common-policies/ 301 /cloudflare-one/api-terraform/gateway-api-examples/network-policy/ /cloudflare-one/policies/gateway/network-policies/common-policies/ 301 /cloudflare-one/api-terraform/gateway-api-examples/http-policy/ /cloudflare-one/policies/gateway/http-policies/common-policies/ 301 +/cloudflare-one/applications/configure-apps/self-hosted-apps/ /cloudflare-one/applications/configure-apps/self-hosted-public-app/ 301 /cloudflare-one/applications/non-http/arbitrary-tcp/ /cloudflare-one/applications/non-http/cloudflared-authentication/arbitrary-tcp/ 301 /cloudflare-one/connections/connect-apps/configuration/ /cloudflare-one/connections/connect-networks/configure-tunnels/ 301 /cloudflare-one/connections/connect-apps/install-and-setup/setup/ /cloudflare-one/connections/connect-networks/get-started/ 301 @@ -1726,6 +1727,7 @@ /cloudflare-one/insights/logs/logpush/rdata/ /cloudflare-one/insights/logs/logpush/#parse-logpush-logs 301 /cloudflare-one/applications/custom-pages/ /cloudflare-one/applications/ 301 /cloudflare-one/identity/service-auth/service-tokens/ /cloudflare-one/identity/service-tokens/ 301 +/cloudflare-one/identity/users/groups/ /cloudflare-one/policies/access/groups/ 301 /cloudflare-one/identity/users/short-lived-certificates/ /cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/ 301 /cloudflare-one/identity/users/validating-json/ /cloudflare-one/identity/authorization-cookie/validating-json/ 301 /cloudflare-one/policies/gateway/configuring-block-page/ /cloudflare-one/policies/gateway/block-page/ 301 @@ -1764,9 +1766,9 @@ /cloudflare-one/tutorials/block-tld/ /cloudflare-one/policies/gateway/dns-policies/common-policies/#block-sites-by-top-level-domain 301 /cloudflare-one/tutorials/block-uploads/ /cloudflare-one/policies/gateway/http-policies/common-policies/#block-google-drive-uploads 301 /cloudflare-one/tutorials/corp-device-tag/ /cloudflare-one/identity/devices/ 301 -/cloudflare-one/tutorials/country-rules/ /cloudflare-one/identity/users/groups/ 301 +/cloudflare-one/tutorials/country-rules/ /cloudflare-one/policies/access/groups/ 301 /cloudflare-one/tutorials/credentials-only/ /cloudflare-one/connections/connect-networks/get-started/ 301 -/cloudflare-one/tutorials/default-groups/ /cloudflare-one/identity/users/groups/ 301 +/cloudflare-one/tutorials/default-groups/ /cloudflare-one/policies/access/groups/ 301 /cloudflare-one/tutorials/do-not-decrypt/ /cloudflare-one/policies/gateway/http-policies/common-policies/#skip-inspection-for-groups-of-applications 301 /cloudflare-one/tutorials/gateway-list/ /cloudflare-one/policies/gateway/lists/ 301 /cloudflare-one/tutorials/identity-dns/ /cloudflare-one/policies/gateway/dns-policies/common-policies/#restrict-access-to-specific-groups 301 diff --git a/src/assets/images/cloudflare-one/applications/network-diagram.png b/src/assets/images/cloudflare-one/applications/network-diagram.png deleted file mode 100644 index 60ebdd75cce3bf..00000000000000 Binary files a/src/assets/images/cloudflare-one/applications/network-diagram.png and /dev/null differ diff --git a/src/assets/images/cloudflare-one/secure-origin-connections/mongodb-tunnel/add-app.png b/src/assets/images/cloudflare-one/secure-origin-connections/mongodb-tunnel/add-app.png deleted file mode 100644 index dfaa25a3dd839d..00000000000000 Binary files a/src/assets/images/cloudflare-one/secure-origin-connections/mongodb-tunnel/add-app.png and /dev/null differ diff --git a/src/assets/images/cloudflare-one/secure-origin-connections/mongodb-tunnel/add-rules.png b/src/assets/images/cloudflare-one/secure-origin-connections/mongodb-tunnel/add-rules.png deleted file mode 100644 index fba74384770760..00000000000000 Binary files a/src/assets/images/cloudflare-one/secure-origin-connections/mongodb-tunnel/add-rules.png and /dev/null differ diff --git a/src/assets/images/cloudflare-one/zero-trust-security/ssh/app-list.png b/src/assets/images/cloudflare-one/zero-trust-security/ssh/app-list.png deleted file mode 100644 index e467d78019ae8c..00000000000000 Binary files a/src/assets/images/cloudflare-one/zero-trust-security/ssh/app-list.png and /dev/null differ diff --git a/src/assets/images/cloudflare-one/zero-trust-security/vnc-client-in-browser/vnc-domain-application.png b/src/assets/images/cloudflare-one/zero-trust-security/vnc-client-in-browser/vnc-domain-application.png deleted file mode 100644 index a5b50c30ae935a..00000000000000 Binary files a/src/assets/images/cloudflare-one/zero-trust-security/vnc-client-in-browser/vnc-domain-application.png and /dev/null differ diff --git a/src/assets/images/cloudflare-one/zero-trust-security/vnc-client-in-browser/vnc-policy.png b/src/assets/images/cloudflare-one/zero-trust-security/vnc-client-in-browser/vnc-policy.png deleted file mode 100644 index 1d98c73df4ecdf..00000000000000 Binary files a/src/assets/images/cloudflare-one/zero-trust-security/vnc-client-in-browser/vnc-policy.png and /dev/null differ diff --git a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/secure-with-access.mdx b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/secure-with-access.mdx index 54dd94edf162a1..d1d181653f56fd 100644 --- a/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/secure-with-access.mdx +++ b/src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/security/secure-with-access.mdx @@ -23,8 +23,7 @@ Cloudflare Access provides visibility and control over who has access to your [c 2. Go to **Access** > **Applications**. 3. Select **Add an application** and, for type of application, select **Self-hosted**. 4. Enter a name for your Access application and, in **Session Duration**, choose how often the user's [application token](/cloudflare-one/identity/authorization-cookie/application-token/) should expire. -5. In the **Domain** field, insert the custom hostname (for example, `mycustomhostname.com`) and press enter. The custom hostname will not appear in the dropdown and must be manually entered. - :::caution[Domain field validation] - Since the custom hostname zone must be managed externally to Cloudflare or in a separate Cloudflare account, it is expected that you find a validation warning `Zone is not associated with the current account`. You can proceed with the configuration despite this message. - ::: -6. Follow the remaining [self-hosted application creation steps](/cloudflare-one/applications/configure-apps/self-hosted-apps/) to publish the application. +5. Select **Add public hostname**. +6. For **Input method**, select _Custom_. +7. In **Hostname**, enter your custom hostname (for example, `mycustomhostname.com`). +8. Follow the remaining [self-hosted application creation steps](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to publish the application. diff --git a/src/content/docs/cloudflare-one/api-terraform/access-api-examples/access-group.mdx b/src/content/docs/cloudflare-one/api-terraform/access-api-examples/access-group.mdx index 3eeffd6d413fef..12ec3662c3b016 100644 --- a/src/content/docs/cloudflare-one/api-terraform/access-api-examples/access-group.mdx +++ b/src/content/docs/cloudflare-one/api-terraform/access-api-examples/access-group.mdx @@ -1,13 +1,13 @@ --- type: example -summary: Use a pre-existing Access group. +summary: Use a pre-existing rule group. tags: - - Access group -title: Access group + - Rule group +title: Rule group pcx_content_type: example sidebar: order: 4 -description: Use a pre-existing Access group. +description: Use a pre-existing rule group. --- diff --git a/src/content/docs/cloudflare-one/applications/configure-apps/dash-sso-apps.mdx b/src/content/docs/cloudflare-one/applications/configure-apps/dash-sso-apps.mdx index 0bd6d38b728eca..8a216ae513151e 100644 --- a/src/content/docs/cloudflare-one/applications/configure-apps/dash-sso-apps.mdx +++ b/src/content/docs/cloudflare-one/applications/configure-apps/dash-sso-apps.mdx @@ -2,7 +2,7 @@ pcx_content_type: how-to title: Cloudflare dashboard SSO application sidebar: - order: 3 + order: 4 --- @@ -40,7 +40,7 @@ Once your SSO domain is approved, a new **SSO App** application will appear unde :::note -We recommend noting down your [Global API key](/fundamentals/api/get-started/keys/) in case you need to [disable SSO](#option-2-disable-dashboard-sso) later. +We recommend noting down your [Global API key](/fundamentals/api/get-started/keys/) in case you need to [disable SSO](#option-2-disable-dashboard-sso) later. ::: 1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Settings** > **Authentication**. diff --git a/src/content/docs/cloudflare-one/applications/configure-apps/index.mdx b/src/content/docs/cloudflare-one/applications/configure-apps/index.mdx index f3cfed77f14208..dbb4b93f1b2510 100644 --- a/src/content/docs/cloudflare-one/applications/configure-apps/index.mdx +++ b/src/content/docs/cloudflare-one/applications/configure-apps/index.mdx @@ -6,16 +6,16 @@ sidebar: --- -Cloudflare Access allows you to secure your web applications by acting as an identity aggregator, or proxy. Users can only log in to the application if they meet the criteria you want to introduce. +Cloudflare Access allows you to secure your web applications by acting as an identity aggregator, or proxy. You can use signals from your existing identity providers (IdPs), device posture providers, and [other rules](/cloudflare-one/policies/access/#selectors) to control who can log in to the application. ![Cloudflare Access verifies a user's identity before granting access to your application.](~/assets/images/cloudflare-one/applications/diagram-saas.jpg) -You can protect two types of web applications: SaaS and self-hosted. +You can protect the following types of web applications: -* [**SaaS applications**](/cloudflare-one/applications/configure-apps/saas-apps/) consist of applications your team relies on that are not hosted by your organization. Examples include Salesforce and Workday. To secure SaaS applications, you must integrate Cloudflare Access with the SaaS application's SSO configuration. +- [**SaaS applications**](/cloudflare-one/applications/configure-apps/saas-apps/) consist of applications your team relies on that are not hosted by your organization. Examples include Salesforce and Workday. To secure SaaS applications, you must integrate Cloudflare Access with the SaaS application's SSO configuration. -* [**Self-hosted applications**](/cloudflare-one/applications/configure-apps/self-hosted-apps/) consist of internal applications that you host in your own environment. These can be the data center versions of tools like the Atlassian suite or applications created by your own team. To secure self-hosted applications, you must use Cloudflare's DNS ([full setup](/dns/zone-setups/full-setup/) or [partial CNAME setup](/dns/zone-setups/partial-setup/)) and [connect the application](/cloudflare-one/connections/connect-networks/) to Cloudflare. +- **Self-hosted applications** consist of internal applications that you host in your own environment. These can be the data center versions of tools like the Atlassian suite or applications created by your own team. Setup requirements for a self-hosted application depend on whether the application is publicly accessible on the Internet or restricted to users on a private network. + - [**Public hostname applications**](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) are web applications that have public DNS records. Anyone on the Internet can access the application by entering the URL in their browser and authenticating through Cloudflare Access. Securing access to a public website requires a Cloudflare DNS [full setup](/dns/zone-setups/full-setup/) or [partial CNAME setup](/dns/zone-setups/partial-setup/). + - [**Private network applications**](/cloudflare-one/applications/non-http/self-hosted-private-app/) do not have public DNS records, meaning they are not reachable from the public Internet. To connect using a private IP or private hostname, the user's traffic must route through Cloudflare Gateway. The preferred method is to install the WARP client on the user's device, but you could also forward device traffic from a [network location](/magic-wan/) or use an agentless option such as [PAC files](/cloudflare-one/connections/connect-devices/agentless/pac-files/) or [Clientless Web Isolation](/cloudflare-one/policies/browser-isolation/setup/clientless-browser-isolation/). -* [**Cloudflare Dashboard SSO**](/cloudflare-one/applications/configure-apps/dash-sso-apps/) are a special type of SaaS application that manages SSO settings for the Cloudflare dashboard and has limited permissions for administrator edits. - -* [**Private network applications**](/cloudflare-one/connections/connect-networks/private-net/) are self-hosted applications that do not have public DNS records, meaning they are not reachable from the public Internet. To allow remote users to access these applications, you must [connect the private network](/cloudflare-one/connections/connect-networks/private-net/cloudflared/) to Cloudflare. +- [**Cloudflare Dashboard SSO**](/cloudflare-one/applications/configure-apps/dash-sso-apps/) is a special type of SaaS application that manages SSO settings for the Cloudflare dashboard and has limited permissions for administrator edits. \ No newline at end of file diff --git a/src/content/docs/cloudflare-one/applications/configure-apps/self-hosted-apps.mdx b/src/content/docs/cloudflare-one/applications/configure-apps/self-hosted-apps.mdx deleted file mode 100644 index b380cb3b707ed1..00000000000000 --- a/src/content/docs/cloudflare-one/applications/configure-apps/self-hosted-apps.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -pcx_content_type: how-to -title: Self-hosted applications -sidebar: - order: 2 - ---- - -import { Render } from "~/components" - - - -![Cloudflare Access authenticates users to your internal applications.](~/assets/images/cloudflare-one/applications/network-diagram.png) - -## Prerequisites - -* An [active domain on Cloudflare](/fundamentals/setup/manage-domains/add-site/) -* Domain uses either a [full setup](/dns/zone-setups/full-setup/) or a [partial (`CNAME`) setup](/dns/zone-setups/partial-setup/) - -## 1. Add your application to Access - - - -## 2. Add an Access policy - - - -## 3. (Optional) Configure advanced settings - - - -## 4. Connect your origin to Cloudflare - -Next, set up a [Cloudflare Tunnel](/cloudflare-one/connections/connect-networks/) to make your internal application available over the Internet. - -## 5. Validate the Access token - - - -Users can now connect to your self-hosted application after authenticating with Cloudflare Access. - -## Product compatibility - -When using Access self-hosted applications, the majority of Cloudflare products will be compatible with your application. - -However, the following products are not supported: - -* [Automatic Signed Exchanges](/speed/optimization/other/signed-exchanges/) -* [Automatic Platform Optimization](/automatic-platform-optimization) -* [Zaraz](/zaraz) - -You can disable Automatic Signed Exchanges and Zaraz for a specific application - instead of across your entire zone - using a [Configuration Rule](/rules/configuration-rules/) scoped to the application domain. diff --git a/src/content/docs/cloudflare-one/applications/configure-apps/self-hosted-public-app.mdx b/src/content/docs/cloudflare-one/applications/configure-apps/self-hosted-public-app.mdx new file mode 100644 index 00000000000000..4c04c77feacc0e --- /dev/null +++ b/src/content/docs/cloudflare-one/applications/configure-apps/self-hosted-public-app.mdx @@ -0,0 +1,48 @@ +--- +pcx_content_type: how-to +title: Publish a self-hosted application to the Internet +sidebar: + order: 2 + label: Self-hosted public application +--- + +import { Render } from "~/components" + +You can securely publish internal tools and applications by adding Cloudflare Access as an authentication layer between the end user and your origin server. + +## Prerequisites + +- An [active domain on Cloudflare](/fundamentals/setup/manage-domains/add-site/) +- Domain uses either a [full setup](/dns/zone-setups/full-setup/) or a [partial (`CNAME`) setup](/dns/zone-setups/partial-setup/) + +## 1. Add your application to Access + + + +## 2. Connect your origin to Cloudflare + +[Set up a Cloudflare Tunnel](/cloudflare-one/connections/connect-networks/get-started/create-remote-tunnel/) to publish your internal application. Only users who match your Access policies will be granted access. + +:::note +We recommend [creating an Access application](#1-add-your-application-to-access) before setting up the tunnel route. If you do not have an Access application in place, public hostname routes in Tunnel are available to anyone on the Internet. +::: + +If your application is already publicly routable, a Tunnel is not strictly required. However, you will then need to protect your origin IP using [other methods](/fundamentals/basic-tasks/protect-your-origin-server/). + +## 3. Validate the Access token + + + +Users can now connect to your self-hosted application after authenticating with Cloudflare Access. + +## Product compatibility + +When using Access self-hosted applications, the majority of Cloudflare products will be compatible with your application. + +However, the following products are not supported: + +* [Automatic Signed Exchanges](/speed/optimization/other/signed-exchanges/) +* [Automatic Platform Optimization](/automatic-platform-optimization) +* [Zaraz](/zaraz) + +You can disable Automatic Signed Exchanges and Zaraz for a specific application - instead of across your entire zone - using a [Configuration Rule](/rules/configuration-rules/) scoped to the application domain. diff --git a/src/content/docs/cloudflare-one/applications/non-http/index.mdx b/src/content/docs/cloudflare-one/applications/non-http/index.mdx index c6d9219778aba5..044fc9ec878a2b 100644 --- a/src/content/docs/cloudflare-one/applications/non-http/index.mdx +++ b/src/content/docs/cloudflare-one/applications/non-http/index.mdx @@ -14,9 +14,9 @@ Non-HTTP applications require [connecting your private network](/cloudflare-one/ ## WARP client -Users can connect by installing the Cloudflare WARP client on their device and enrolling in your Zero Trust organization. Remote devices connect to your applications as if they were on your private network. By default, all devices enrolled in your organization can access the application unless you build policies to allow or block specific users. +Users can connect by installing the Cloudflare WARP client on their device and enrolling in your Zero Trust organization. Remote devices connect to your applications as if they were on your private network. By default, all devices enrolled in your organization can access any private route unless they are protected by an Access policy or Gateway firewall rule. To secure the application, you can [create a self-hosted application](/cloudflare-one/applications/non-http/self-hosted-private-app/) for a private IP range, port range, and/or hostname and build [Access policies](/cloudflare-one/policies/access/) that allow or block specific users. -If you would like to define how users access specific infrastructure servers within your network, create an infrastructure application in [Access for Infrastructure](/cloudflare-one/applications/non-http/infrastructure-apps/). Access for Infrastructure provides an additional layer of control and visibility over how users access non-HTTP applications, including: +If you would like to define how users access specific infrastructure servers within your network, [create an infrastructure application](/cloudflare-one/applications/non-http/infrastructure-apps/) in Access for Infrastructure. Access for Infrastructure provides an additional layer of control and visibility over how users access non-HTTP applications, including: - Define fine-grained policies to govern who has access to specific servers and exactly how a user may access that server. - Eliminate SSH keys by using short-lived certificates to authenticate users. @@ -42,4 +42,4 @@ To connect to an application over a specific protocol, refer to these tutorials: * [SSH](/cloudflare-one/connections/connect-networks/use-cases/ssh/) * [SMB](/cloudflare-one/connections/connect-networks/use-cases/smb/) -* [RDP](/cloudflare-one/connections/connect-networks/use-cases/rdp/) \ No newline at end of file +* [RDP](/cloudflare-one/connections/connect-networks/use-cases/rdp/) diff --git a/src/content/docs/cloudflare-one/applications/non-http/legacy-private-network-app.mdx b/src/content/docs/cloudflare-one/applications/non-http/legacy-private-network-app.mdx new file mode 100644 index 00000000000000..9fe81db67fed37 --- /dev/null +++ b/src/content/docs/cloudflare-one/applications/non-http/legacy-private-network-app.mdx @@ -0,0 +1,53 @@ +--- +pcx_content_type: how-to +title: Private network applications (legacy) +sidebar: + order: 4 + label: Private network applications (legacy) +--- + +:::note +Not recommended for new deployments. We recommend using a [self-hosted application](/cloudflare-one/applications/non-http/self-hosted-private-app/) to secure a private IP address. +::: + +You can configure a **Private Network** application to manage access to specific applications on your private network. + +To create a private network application: + +1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications** > **Add an application**. + +2. Select **Private Network**. + +3. Name your application. + +4. For **Application type**, select _Destination IP_. + +5. For **Value**, enter the IP address for your application (for example, `10.128.0.7`). + :::note + If you would like to create a policy for an IP/CIDR range instead of a specific IP address, you can build a [Gateway Network policy](/cloudflare-one/policies/gateway/network-policies/) using the **Destination IP** selector. + ::: + +6. Configure your [App Launcher](/cloudflare-one/applications/app-launcher/) visibility and logo. + +7. Select **Next**. You will see two auto-generated Gateway Network policies: one that allows access to the destination IP and another that blocks access. + +8. Modify the policies to include additional identity-based conditions. For example: + + - **Policy 1** + + | Selector | Operator | Value | Logic | Action | + | -------------- | ------------- | ---------------- | ----- | ------ | + | Destination IP | in | `10.128.0.7` | And | Allow | + | User Email | matches regex | `.*@example.com` | | | + + - **Policy 2** + + | Selector | Operator | Value | Action | + | -------------- | -------- | ------------ | ------ | + | Destination IP | in | `10.128.0.7` | Block | + + Policies are evaluated in [numerical order](/cloudflare-one/policies/gateway/order-of-enforcement/#order-of-precedence), so a user with an email ending in @example.com will be able to access `10.128.0.7` while all others will be blocked. For more information on building network policies, refer to our [dedicated documentation](/cloudflare-one/policies/gateway/network-policies/). + +9. Select **Add application**. + +Your application will appear on the **Applications** page. \ No newline at end of file diff --git a/src/content/docs/cloudflare-one/applications/non-http/self-hosted-private-app.mdx b/src/content/docs/cloudflare-one/applications/non-http/self-hosted-private-app.mdx new file mode 100644 index 00000000000000..dbaa60ab5cc0cc --- /dev/null +++ b/src/content/docs/cloudflare-one/applications/non-http/self-hosted-private-app.mdx @@ -0,0 +1,81 @@ +--- +pcx_content_type: how-to +title: Secure a private IP or hostname +sidebar: + order: 3 + label: Add a self-hosted private application +--- + +import { Render } from "~/components" + +You can configure a self-hosted Access application to manage access to specific IPs or hostnames on your private network. + +:::note +This feature is available in early access and replaces the legacy [private network app type](/cloudflare-one/applications/non-http/legacy-private-network-app/). To request access, contact your account team. +::: + +## Prerequisites + +- Private IPs and hostnames are reachable over Cloudflare WARP, Magic WAN or Browser Isolation. For more details, refer to [Connect a private network](/cloudflare-one/connections/connect-networks/private-net/). +- Private hostnames route to your custom DNS resolver through [Local Domain Fallback](/cloudflare-one/connections/connect-devices/warp/configure-warp/route-traffic/local-domains/) or [Gateway resolver policies](/cloudflare-one/policies/gateway/resolver-policies/). +- [Gateway TLS decryption](/cloudflare-one/policies/gateway/http-policies/tls-decryption/) must be enabled if you would like to present a login page in the browser and issue an authorization JWT to your origin. Otherwise, users will receive a pop-up notification from the WARP client and all session management will be handled in the WARP client. + +## Add your application to Access + +1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. + +2. Select **Add an application**. + +3. Select **Self-hosted**. + +4. Enter any name for the application. + +5. In **Session Duration**, choose how often the user's [application token](/cloudflare-one/identity/authorization-cookie/application-token/) should expire. + + Cloudflare checks every HTTPS request to your application for a valid application token. If the user's application token (and global token) has expired, they will be prompted to reauthenticate with the IdP. For more information, refer to [Session management](/cloudflare-one/identity/users/session-management/). If the application is non-HTTPS or you do not have TLS decryption turned on, the session is tracked by the WARP client per application. + +6. Add the private IP and/or private hostname that represents the application. You can use [wildcards](/cloudflare-one/policies/access/app-paths/) with private hostnames to protect multiple parts of an application that share a root path. + + :::note + Private hostnames are currently only available over port `443` over HTTPS and the application must have a valid Server Name Indicator (SNI). + ::: + +7. Add [Access policies](/cloudflare-one/policies/access/) to control who can connect to your application. All Access applications are deny by default -- a user must match an Allow policy before they are granted access. + +8. + +9. Select **Next**. + +10. (Optional) Configure [App Launcher settings](/cloudflare-one/applications/app-launcher/) for the application. + +11. + +12. Select **Next**. + +13. (Optional) Configure advanced settings. These settings only apply to private hostnames and require Gateway TLS decryption. + + - [**Cross-Origin Resource Sharing (CORS) settings**](/cloudflare-one/identity/authorization-cookie/cors/) + - [**Cookie settings**](/cloudflare-one/identity/authorization-cookie/#cookie-settings) + - **Browser rendering settings**: + - [Automatic `cloudflared` authentication](/cloudflare-one/applications/non-http/cloudflared-authentication/automatic-cloudflared-authentication/) + - [Browser rendering for SSH and VNC](/cloudflare-one/applications/non-http/browser-rendering/) + - **401 Response for Service Auth policies**: Return a `401` response code when a user (or machine) makes a request to the application without the correct [service token](/cloudflare-one/identity/service-tokens/). + +14. Select **Save**. + +Users can now connect to your private application after authenticating with Cloudflare Access. + +## Modify order of precedence in Gateway + +By default, Cloudflare will evaluate a private application's Access policies after evaluating all Gateway network policies. To evaluate Access private applications before or after specific Gateway policies, create the following [Gateway network policy](/cloudflare-one/policies/gateway/network-policies/): + + +| Selector | Operator | Value | Action | +| -------- | -------- | ------------ | ------ | +| All Access Private Apps | is | `Enabled` | Allow | + +You can now drag and drop this policy in the Gateway policy builder to change its [order of precedence](/cloudflare-one/policies/gateway/order-of-enforcement/#order-of-precedence). + +:::note +Users must pass the policies in your Access application before they are granted access. The Gateway Allow policy is strictly for routing and connectivity purposes. +::: diff --git a/src/content/docs/cloudflare-one/applications/non-http/short-lived-certificates-legacy.mdx b/src/content/docs/cloudflare-one/applications/non-http/short-lived-certificates-legacy.mdx index e50bc1c12c7e2c..4cf6e863c8bca0 100644 --- a/src/content/docs/cloudflare-one/applications/non-http/short-lived-certificates-legacy.mdx +++ b/src/content/docs/cloudflare-one/applications/non-http/short-lived-certificates-legacy.mdx @@ -24,7 +24,7 @@ Cloudflare Access short-lived certificates can work with any modern SSH server, To secure your server behind Cloudflare Access: 1. Connect the server to Cloudflare as a [public hostname route](/cloudflare-one/connections/connect-networks/use-cases/ssh/#1-connect-the-server-to-cloudflare-1). -2. Create a [self-hosted Access application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) for the server. +2. Create a [self-hosted Access application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) for the server. :::note If you do not wish to use Access, refer instead to our [SSH proxy instructions](/cloudflare-one/policies/gateway/network-policies/ssh-logging/). diff --git a/src/content/docs/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-modes/device-information-only.mdx b/src/content/docs/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-modes/device-information-only.mdx index 8fdb863c51199c..88645ff497a5f3 100644 --- a/src/content/docs/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-modes/device-information-only.mdx +++ b/src/content/docs/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-modes/device-information-only.mdx @@ -8,7 +8,7 @@ sidebar: import { TabItem, Tabs } from "~/components" -Device Information Only mode allows you to enforce device posture rules when a user connects to your [self-hosted Access application](/cloudflare-one/applications/configure-apps/self-hosted-apps/). This mode relies on a client certificate generated from your account to establish trust between the Access application and the device. +Device Information Only mode allows you to enforce device posture rules when a user connects to your [self-hosted Access application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/). This mode relies on a client certificate generated from your account to establish trust between the Access application and the device. To set up Device Information Only mode: diff --git a/src/content/docs/cloudflare-one/connections/connect-networks/deploy-tunnels/tunnel-with-firewall.mdx b/src/content/docs/cloudflare-one/connections/connect-networks/deploy-tunnels/tunnel-with-firewall.mdx index 16d9512ea66262..2b7281bcda2a84 100644 --- a/src/content/docs/cloudflare-one/connections/connect-networks/deploy-tunnels/tunnel-with-firewall.mdx +++ b/src/content/docs/cloudflare-one/connections/connect-networks/deploy-tunnels/tunnel-with-firewall.mdx @@ -91,7 +91,7 @@ Alternatively, you may use operating system (OS)-level firewall rules to block a Run your tunnel and check that all configured services are still accessible to the outside world via the tunnel, but not via the external IP address of the server. -You can also [secure your application with Cloudflare Access](/cloudflare-one/applications/configure-apps/self-hosted-apps/). +You can also [secure your application with Cloudflare Access](/cloudflare-one/applications/configure-apps/self-hosted-public-app/). ## Test connectivity diff --git a/src/content/docs/cloudflare-one/connections/connect-networks/get-started/create-remote-tunnel.mdx b/src/content/docs/cloudflare-one/connections/connect-networks/get-started/create-remote-tunnel.mdx index 66797c54eccbf9..a20dc6623f124c 100644 --- a/src/content/docs/cloudflare-one/connections/connect-networks/get-started/create-remote-tunnel.mdx +++ b/src/content/docs/cloudflare-one/connections/connect-networks/get-started/create-remote-tunnel.mdx @@ -29,6 +29,8 @@ Follow these steps to connect an application through your tunnel. If you are loo +The application is now publicly available on the Internet. To allow or block specific users, [create an Access application](/cloudflare-one/applications/configure-apps/self-hosted-public-app). + ## 3. Connect a network Follow these steps to connect a private network through your tunnel. @@ -37,8 +39,11 @@ Follow these steps to connect a private network through your tunnel. 2. Select **Save tunnel**. +To configure Zero Trust policies and connect as a user, refer to [Connect private networks](/cloudflare-one/connections/connect-networks/private-net/cloudflared/). + ## 4. View your tunnel After saving the tunnel, you will be redirected to the **Tunnels** page. Look for your new tunnel to be listed along with its active connector. ![Tunnel appearing in the Tunnels table](~/assets/images/cloudflare-one/connections/connect-apps/tunnel-table.png) + diff --git a/src/content/docs/cloudflare-one/connections/connect-networks/private-net/cloudflared/index.mdx b/src/content/docs/cloudflare-one/connections/connect-networks/private-net/cloudflared/index.mdx index 8dcb4b58a49b44..0f7a040557307b 100644 --- a/src/content/docs/cloudflare-one/connections/connect-networks/private-net/cloudflared/index.mdx +++ b/src/content/docs/cloudflare-one/connections/connect-networks/private-net/cloudflared/index.mdx @@ -32,53 +32,15 @@ To connect your infrastructure with Cloudflare Tunnel: ## 4. (Recommended) Filter network traffic with Gateway -By default, all WARP devices enrolled in your Zero Trust organization can connect to your private network through Cloudflare Tunnel. You can configure Gateway to inspect your network traffic and either block or allow access based on user identity and device posture. +By default, all WARP devices enrolled in your Zero Trust organization can connect to your private network through Cloudflare Tunnel. You can configure Gateway inspect your network traffic and either block or allow access based on user identity and device posture. ### Enable the Gateway proxy -### Create Zero Trust policies +### Zero Trust policies -You can create Zero Trust policies to manage access to specific applications on your network. - -1. Go to **Access** > **Applications** > **Add an application**. - -2. Select **Private Network**. - -3. Name your application. - -4. For **Application type**, select _Destination IP_. - -5. For **Value**, enter the IP address for your application (for example, `10.128.0.7`). - :::note - If you would like to create a policy for an IP/CIDR range instead of a specific IP address, you can build a [Gateway Network policy](/cloudflare-one/policies/gateway/network-policies/) using the **Destination IP** selector. - ::: - -6. Configure your [App Launcher](/cloudflare-one/applications/app-launcher/) visibility and logo. - -7. Select **Next**. You will see two auto-generated Gateway Network policies: one that allows access to the destination IP and another that blocks access. - -8. Modify the policies to include additional identity-based conditions. For example: - - - **Policy 1** - - | Selector | Operator | Value | Logic | Action | - | -------------- | ------------- | ---------------- | ----- | ------ | - | Destination IP | in | `10.128.0.7` | And | Allow | - | User Email | matches regex | `.*@example.com` | | | - - - **Policy 2** - - | Selector | Operator | Value | Action | - | -------------- | -------- | ------------ | ------ | - | Destination IP | in | `10.128.0.7` | Block | - - Policies are evaluated in [numerical order](/cloudflare-one/policies/gateway/order-of-enforcement/#order-of-precedence), so a user with an email ending in @example.com will be able to access `10.128.0.7` while all others will be blocked. For more information on building network policies, refer to our [dedicated documentation](/cloudflare-one/policies/gateway/network-policies/). - -9. Select **Add application**. - -Your application will appear on the **Applications** page. +Cloudflare Zero Trust allows you to configure security policies using either Access or Gateway. If you have applications clearly defined by IPs or hostnames, we recommend [creating an Access application](/cloudflare-one/applications/non-http/self-hosted-private-app/) and managing user access alongside your SaaS and other web apps. Alternatively, if you prefer to secure a private network using a traditional firewall model, you can build Gateway [network and DNS policies](/learning-paths/replace-vpn/build-policies/) for IP ranges and domains. ## 5. Connect as a user diff --git a/src/content/docs/cloudflare-one/connections/connect-networks/troubleshoot-tunnels/common-errors.mdx b/src/content/docs/cloudflare-one/connections/connect-networks/troubleshoot-tunnels/common-errors.mdx index cc4eec52999353..2b64bb0dfe3f12 100644 --- a/src/content/docs/cloudflare-one/connections/connect-networks/troubleshoot-tunnels/common-errors.mdx +++ b/src/content/docs/cloudflare-one/connections/connect-networks/troubleshoot-tunnels/common-errors.mdx @@ -5,6 +5,8 @@ sidebar: order: 2 --- +import { Tabs, TabItem } from "~/components"; + This section covers the most common errors you might encounter when connecting resources with Cloudflare Tunnel. If you do not see your issue listed below, refer to the [troubleshooting FAQ](/cloudflare-one/faq/troubleshooting/), view your [Tunnel logs](/cloudflare-one/connections/connect-networks/monitor-tunnels/logs/), or [contact Cloudflare Support](/support/contacting-cloudflare-support/). ## I see `cloudflared service is already installed`. @@ -131,3 +133,43 @@ sudo sysctl -a | grep net.core.rmem_max ```sh output net.core.rmem_max = 2500000 ``` + +## `ping` and `traceroute` commands do not work. + +To ping an IP address behind Cloudflare Tunnel, your system must allow ICMP traffic through `cloudflared`: + + + +1. Ensure that `ping_group_range` includes the Group ID (GID) of the user running `cloudflared`. + + 1. To get the Group ID of the user, run `id -g`. + 2. To verify the Group IDs that are allowed to use ICMP: + + ```sh + sudo sysctl net.ipv4.ping_group_range + ``` + + ```sh output + net.ipv4.ping_group_range= 0 10000 + ``` + + 3. Either add the user to a group within that range, or update the range to encompass a group the user is already in. To update `ping_group_range`: + + ```sh + echo 0 10001 | sudo tee /proc/sys/net/ipv4/ping_group_range + ``` + +2. If you are running multiple network interfaces (for example, `eth0` and `eth1`), configure `cloudflared` to use the external Internet-facing interface: + + ```sh + cloudflared tunnel run --icmpv4-src + ``` + + + +In your environment, modify the `ping_group_range` parameter to include the Group ID (GID) of the user running `cloudflared`. + +By default the [`cloudflared` Docker container](https://github.com/cloudflare/cloudflared/blob/master/Dockerfile#L29C6-L29C13) executes as a user called `nonroot` inside of the container. `nonroot` is a specific user that exists in the [base image](https://github.com/GoogleContainerTools/distroless/blob/859eeea1f9b3b7d59bdcd7e24a977f721e4a406c/base/base.bzl#L8) we use, and its Group ID is hardcoded to 65532. + + + diff --git a/src/content/docs/cloudflare-one/connections/connect-networks/use-cases/rdp.mdx b/src/content/docs/cloudflare-one/connections/connect-networks/use-cases/rdp.mdx index 063d0ffe530a8c..92650f044cdec2 100644 --- a/src/content/docs/cloudflare-one/connections/connect-networks/use-cases/rdp.mdx +++ b/src/content/docs/cloudflare-one/connections/connect-networks/use-cases/rdp.mdx @@ -98,7 +98,7 @@ You now have secure, remote access to the RDP server. 4. Select **Save hostname**. -5. (Recommended) Add a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) to Cloudflare Access in order to manage access to your server. +5. (Recommended) Add a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to Cloudflare Access in order to manage access to your server. ### 2. Connect as a user diff --git a/src/content/docs/cloudflare-one/connections/connect-networks/use-cases/smb.mdx b/src/content/docs/cloudflare-one/connections/connect-networks/use-cases/smb.mdx index 27fa9ac3238381..8c099811d2aafe 100644 --- a/src/content/docs/cloudflare-one/connections/connect-networks/use-cases/smb.mdx +++ b/src/content/docs/cloudflare-one/connections/connect-networks/use-cases/smb.mdx @@ -72,7 +72,7 @@ While SMB was developed for Microsoft Windows, Samba provides SMB connectivity f 4. Select **Save hostname**. -5. (Recommended) Add a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) to Cloudflare Access in order to manage access to your server. +5. (Recommended) Add a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to Cloudflare Access in order to manage access to your server. ### 2. Connect as a user diff --git a/src/content/docs/cloudflare-one/identity/authorization-cookie/index.mdx b/src/content/docs/cloudflare-one/identity/authorization-cookie/index.mdx index e12efd88a1aacf..0b5fce86c4636d 100644 --- a/src/content/docs/cloudflare-one/identity/authorization-cookie/index.mdx +++ b/src/content/docs/cloudflare-one/identity/authorization-cookie/index.mdx @@ -22,7 +22,7 @@ Two tokens are generated: ### Multi-domain applications -Cloudflare Access allows you to protect and manage multiple domains in a single [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-apps/). After a user has successfully authenticated to one domain, Access will automatically issue a `CF_Authorization` cookie when they go to another domain in the same Access application. This means that users only need to authenticate once to a multi-domain application. +Cloudflare Access allows you to protect and manage multiple domains in a single [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/). After a user has successfully authenticated to one domain, Access will automatically issue a `CF_Authorization` cookie when they go to another domain in the same Access application. This means that users only need to authenticate once to a multi-domain application. For Access applications with five or less domains, Access will preemptively set the cookie for all domains through a series of redirects. This allows single-page applications (SPAs) to retrieve data from other subdomains, even if the user has not explicitly visited those subdomains. Note that we cannot set cookies up-front for a wildcarded subdomain, because we do not know which concrete subdomain to redirect to (wildcarded paths are allowed). @@ -85,7 +85,7 @@ The Binding Cookie is an additional cookie created when a user successfully auth Do not enable Binding Cookie if: * You are using the Access application for non-browser based tools (such as SSH or RDP). -* You have enabled [incompatible Cloudflare products](/cloudflare-one/applications/configure-apps/self-hosted-apps/#product-compatibility) on the application domain. +* You have enabled [incompatible Cloudflare products](/cloudflare-one/applications/configure-apps/self-hosted-public-app/#product-compatibility) on the application domain. * You have turned on [WARP authentication identity](/cloudflare-one/connections/connect-devices/warp/configure-warp/warp-sessions/) for the application. ### Cookie Path Attribute diff --git a/src/content/docs/cloudflare-one/identity/devices/service-providers/custom.mdx b/src/content/docs/cloudflare-one/identity/devices/service-providers/custom.mdx index bfc77698eed8db..e73bbb39ac389f 100644 --- a/src/content/docs/cloudflare-one/identity/devices/service-providers/custom.mdx +++ b/src/content/docs/cloudflare-one/identity/devices/service-providers/custom.mdx @@ -96,7 +96,7 @@ WARP uses an Access Client ID and Access Client Secret to securely authenticate Next, secure the external API behind Cloudflare Access so that WARP can authenticate with the service token. To add the API endpoint to Access: -1. [Create a self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) for your API endpoint. +1. [Create a self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) for your API endpoint. 2. Add the following Access policy to the application. Make sure that **Action** is set to _Service Auth_ (not _Allow_). | Action | Rule type | Selector | Value | diff --git a/src/content/docs/cloudflare-one/identity/users/groups.mdx b/src/content/docs/cloudflare-one/identity/users/groups.mdx deleted file mode 100644 index 6b318bc97b1ee1..00000000000000 --- a/src/content/docs/cloudflare-one/identity/users/groups.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -pcx_content_type: concept -title: Access groups -sidebar: - order: 2 - ---- - -import { Render } from "~/components" - -An Access group is a set of rules that can be configured once and then quickly applied across many Access applications. You can assign an Access group to any Access policy, and all the criteria from the selected group will apply to that application. - -:::note - - -Access groups are distinct from groups in your identity provider, like Okta groups. Access groups can contain a mix of individual users, groups from identity providers, and service authentication options like service tokens. - - -::: - -## Create a group - - - -## Group criteria - -Group criteria determine whether or not a user is a member of a particular group. Since groups are simply a collection of Access rules, they use the same [rule types](/cloudflare-one/policies/access/#rule-types) and [selectors](/cloudflare-one/policies/access/#selectors) shown in the Access policy builder. - -## Groups for IP-based rules - -We recommend using groups to define any IP address-based rules you configure in policies. Keeping IP addresses in one place allows you to modify or remove addresses once, rather than in each policy, and reduces the potential for mistakes. - -:::note - - -If adding more than one IP address or range to a group, use an Include rule for the IPs. If you do not use an Include rule, the policy will require traffic to originate from all ranges. - - -::: - -## Groups for country requirements - -You can create an Access group that consists of countries to allow or block. Access will treat the countries in the Include rule with an OR logical operator. When building policies for an Access application, you can assign this Access group to a Require policy to require at least one of the countries inside of the group. diff --git a/src/content/docs/cloudflare-one/identity/users/session-management.mdx b/src/content/docs/cloudflare-one/identity/users/session-management.mdx index 90e08914fe9000..8d4a76d7c25aed 100644 --- a/src/content/docs/cloudflare-one/identity/users/session-management.mdx +++ b/src/content/docs/cloudflare-one/identity/users/session-management.mdx @@ -51,10 +51,9 @@ Access session durations only control the front door to a SaaS app; Access does You can set a policy session duration ranging from immediate timeout to one month. The policy session duration takes precedence over the application session duration. -1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. -2. Locate the application you want to configure and select **Edit**. -3. Go to the **Policies** tab and select **Configure** for any policy. -4. Select a **Session Duration** from the dropdown menu. +1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Policies**. +2. Choose a policy and select **Configure**. +3. Select a **Session Duration** from the dropdown menu. Users who match this policy will be issued an application token with this expiration time. diff --git a/src/content/docs/cloudflare-one/policies/access/app-paths.mdx b/src/content/docs/cloudflare-one/policies/access/app-paths.mdx index 5d8cb109c529cf..3d3d37aedb572d 100644 --- a/src/content/docs/cloudflare-one/policies/access/app-paths.mdx +++ b/src/content/docs/cloudflare-one/policies/access/app-paths.mdx @@ -6,7 +6,7 @@ sidebar: --- -Application paths define the URLs protected by an Access policy. When adding a [self-hosted web application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) to Access, you can choose to protect the entire website by entering its apex domain, or alternatively, protect specific subdomains and paths. +Application paths define the URLs protected by an Access policy. When adding a self-hosted application to Access, you can choose to protect the entire website by entering its apex domain, or alternatively, protect specific subdomains and paths. ## Policy inheritance diff --git a/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx b/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx index ebdf8c6d533552..b5ed268f0a3221 100644 --- a/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx +++ b/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx @@ -106,19 +106,25 @@ Other key formats (such as DSA) are not supported at this time. ### 4. Create an External Evaluation rule -1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. +1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Policies**. -2. Find the application for which you want to apply the External Evaluation rule and select **Edit**. +2. Edit an existing policy or select **Add a policy**. -3. In the **Policies** tab, edit an existing policy or select **Add a policy**. - -4. Add the following rule to your policy: +3. Add the following rule to your policy: | Rule Type | Selector | Evaluate URL | Keys URL | | --------- | ------------------- | ------------------------------------------------- | ------------------------------------------------------ | | Include | External Evaluation | `https://my-worker..workers.dev/` | `https://my-worker..workers.dev/keys/` | -When a user logs in to your application, Access will now check their email, device, location, and other identity-based data against your business logic. To test your policies against an email, go to the **Policies** tab and select **Test your policies**. +4. Save the policy. + +5. Go to **Access** > **Applications** and edit the application for which you want to apply the External Evaluation rule. + +6. In the **Policies** tab, add the policy that contains the External Evaluation rule. + +7. Select **Save application**. + +When a user logs in to your application, Access will now check their email, device, location, and other identity-based data against your business logic. ### Troubleshooting the Worker diff --git a/src/content/docs/cloudflare-one/policies/access/groups.mdx b/src/content/docs/cloudflare-one/policies/access/groups.mdx new file mode 100644 index 00000000000000..e1eebc6c02c08d --- /dev/null +++ b/src/content/docs/cloudflare-one/policies/access/groups.mdx @@ -0,0 +1,33 @@ +--- +pcx_content_type: concept +title: Rule groups +sidebar: + order: 2 + +--- + +import { Render } from "~/components" + +A rule group is a collection of Access rules that can be configured once and then quickly applied across many Access policies. Rule groups use the same [rule types](/cloudflare-one/policies/access/#rule-types) and [selectors](/cloudflare-one/policies/access/#selectors) shown in the Access policy builder. + +:::note +Rule groups are distinct from groups in your identity provider, like Okta groups. Rule groups can contain a mix of individual users, groups from identity providers, and service authentication options like service tokens. +::: + +## Create a rule group + + + +## Use cases + +### IP-based rules + +We recommend using rule groups to define any IP address-based rules you configure in policies. Keeping IP addresses in one place allows you to modify or remove addresses once, rather than in each policy, and reduces the potential for mistakes. + +:::note +If adding more than one IP address or range to a rule group, use an Include rule for the IPs. If you do not use an Include rule, the policy will require traffic to originate from all ranges. +::: + +### Country requirements + +You can create a rule group that consists of countries to allow or block. Access will treat the countries in the Include rule with an OR logical operator. When building policies for an Access application, you can assign this rule group to a Require policy to require at least one of the countries inside of the group. For an example policy, refer to [Require rules with OR operators](/cloudflare-one/policies/access/#require-rules-with-or-operators). diff --git a/src/content/docs/cloudflare-one/policies/access/index.mdx b/src/content/docs/cloudflare-one/policies/access/index.mdx index c864bf2b233c06..c22caaf39c2883 100644 --- a/src/content/docs/cloudflare-one/policies/access/index.mdx +++ b/src/content/docs/cloudflare-one/policies/access/index.mdx @@ -97,33 +97,35 @@ The Exclude rule works like a NOT logical operator. A user meeting any Exclusion The Require rule works like an AND logical operator. A user must meet all specified Require rules to be allowed access. -#### Requiring multiple conditions +#### Require rules with OR operators -When setting up a Require rule for an Access policy, keep in mind that any values you add to the rule will be concatenated by an AND operator. For example, let's say you want to grant access to an application to both the full-time employees and the contractors, and only the ones based in specific countries — say Portugal and the United States. If you set up a rule with the following configuration: +By default, any values added to a Require rule are concatenated by an AND operator. For example, let's say you want to grant access to an application to both the full-time employees and the contractors, and only the ones based in specific countries — say Portugal and the United States. If you set up a rule with the following configuration: | Action | Rule type | Selector | Value | | ------ | --------- | ---------------- | ------------------------------------- | -| Allow | Require | Emails ending in | `@cloudflare.com`, `@contractors.com` | -| | Require | Country | `United States`, `Portugal` | +| Allow | Require | Country | `United States`, `Portugal` | +| | Require | Emails ending in | `@cloudflare.com`, `@contractors.com` | the policy will only grant access to people reaching the application from both the United States AND Portugal, and who have both an email ending in `@cloudflare.com` AND in `@contractors.com`. Therefore, nobody will have access to the application. -Instead, you can address this need by using [Access groups](/cloudflare-one/identity/users/groups/). First, you can set up a group (we will call it `My Access Group`) that includes users in Portugal OR in the United States: +To require only one country and one email ending: -| Rule type | Selector | Value | -| --------- | -------- | --------------------------- | -| Include | Country | `United States`, `Portugal` | +1. [Create a rule group](/cloudflare-one/policies/access/groups/) that includes users in Portugal OR in the United States: -Next, you can create a policy for your application that requires the group, and that also includes users with emails ending in either `@cloudflare.com` OR `@contractors.com`: + | Rule type | Selector | Value | + | --------- | -------- | --------------------------- | + | Include | Country | `United States`, `Portugal` | -| Action | Rule type | Selector | Value | -| ------ | --------- | ----------------- | ------------------------------------- | -| Allow | Require | `My Access Group` | - | -| | Include | Emails ending in | `@cloudflare.com`, `@contractors.com` | +2. Create a policy that requires the rule group, and that also includes users with emails ending in either `@cloudflare.com` OR `@contractors.com`: + + | Action | Rule type | Selector | Value | + | ------ | --------- | ----------------- | ------------------------------------- | + | Allow | Require | Rule group | `Country requirements` | + | | Include | Emails ending in | `@cloudflare.com`, `@contractors.com` | ## Selectors -When you add a rule to your policy, you will be asked to specify the criteria/attributes you want users to meet. These attributes are available for all Access application types, including [SaaS](/cloudflare-one/applications/configure-apps/saas-apps/), [self-hosted](/cloudflare-one/applications/configure-apps/self-hosted-apps/), and [non-HTTP](/cloudflare-one/applications/non-http/) applications. +When you add a rule to your policy, you will be asked to specify the criteria/attributes you want users to meet. These attributes are available for all Access application types, including [SaaS](/cloudflare-one/applications/configure-apps/saas-apps/), [self-hosted](/cloudflare-one/applications/configure-apps/self-hosted-public-app/), and [non-HTTP](/cloudflare-one/applications/non-http/) applications. Identity-based attributes are only checked when a user authenticates to Access, whereas non-identity attributes are polled continuously for changes during the [user session](/cloudflare-one/identity/users/session-management/). If you have configured [SCIM provisioning](/cloudflare-one/identity/users/scim/), you can force a user to re-attest all attributes with Access whenever you revoke the user in the IdP or update their IdP group membership. diff --git a/src/content/docs/cloudflare-one/policies/access/isolate-application.mdx b/src/content/docs/cloudflare-one/policies/access/isolate-application.mdx index 9d17ba8da42e8a..37b6644357e88f 100644 --- a/src/content/docs/cloudflare-one/policies/access/isolate-application.mdx +++ b/src/content/docs/cloudflare-one/policies/access/isolate-application.mdx @@ -10,7 +10,7 @@ import { Render } from "~/components" :::note -Requires [Cloudflare Browser Isolation](/cloudflare-one/policies/browser-isolation/). +Requires [Cloudflare Browser Isolation](/cloudflare-one/policies/browser-isolation/). ::: With Access policies, you can require users to open self-hosted applications in a secure [remote browser](/cloudflare-one/policies/browser-isolation/). Because the remote browser is directly integrated into our Secure Web Gateway platform, [HTTP policies](/cloudflare-one/policies/gateway/http-policies/) can be applied to isolated applications without needing to install the WARP client. This allows you to distribute internal applications to unmanaged users while retaining control over sensitive data. @@ -40,4 +40,4 @@ For example, if your application is hosted on `internal.site.com`, the following ## Product compatibility -For a list of products that are incompatible with the **Isolate application** feature, refer to [Product Compatibility](/cloudflare-one/applications/configure-apps/self-hosted-apps/#product-compatibility) . +For a list of products that are incompatible with the **Isolate application** feature, refer to [Product Compatibility](/cloudflare-one/applications/configure-apps/self-hosted-public-app/#product-compatibility) . diff --git a/src/content/docs/cloudflare-one/policies/access/mfa-requirements.mdx b/src/content/docs/cloudflare-one/policies/access/mfa-requirements.mdx index a35b76f395f224..5ab03830f9e99e 100644 --- a/src/content/docs/cloudflare-one/policies/access/mfa-requirements.mdx +++ b/src/content/docs/cloudflare-one/policies/access/mfa-requirements.mdx @@ -26,7 +26,7 @@ To enforce an MFA requirement to an application: 4. If your application already has a rule containing an identity requirement, find it and select **Edit**. - The rule must contain an Include rule which defines an identity. For example, the Include rule should allow for users who are part of a user [group](/cloudflare-one/identity/users/groups/), email domain, or identity provider group. + The rule must contain an Include rule which defines an identity. For example, the Include rule should allow for users who are part of a [rule group](/cloudflare-one/policies/access/groups/), email domain, or identity provider group. 5. Add a _Require_ action to the rule. diff --git a/src/content/docs/cloudflare-one/policies/access/policy-management.mdx b/src/content/docs/cloudflare-one/policies/access/policy-management.mdx index fc756b7c9c995a..c2bf24263b1cf4 100644 --- a/src/content/docs/cloudflare-one/policies/access/policy-management.mdx +++ b/src/content/docs/cloudflare-one/policies/access/policy-management.mdx @@ -6,47 +6,46 @@ sidebar: --- -Access policies are properties of applications. When setting up an Access application, you will be prompted to create at least one policy for the application. You can go back and create, edit, or delete policies at any time. +import {Tabs, TabItem } from "~/components"; + +Access policies define the users who can log in to your Access applications. You can create, edit, or delete policies at any time and reuse policies across multiple applications. ## Create a policy -To create an Access policy for an existing application: +To create a reusable Access policy: -1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. -2. Locate the application for which you want to create the policy and select **Edit**. -3. Select **Add a policy**. -4. Enter a **Policy name**. This name will identify your policy in the list of application policies. -5. Choose an [**Action**](/cloudflare-one/policies/access/#actions) for the policy. +1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Policies**. +2. Select **Add a policy**. +3. Enter a **Policy name**. +4. Choose an [**Action**](/cloudflare-one/policies/access/#actions) for the policy. +5. Choose a [**Session duration**](/cloudflare-one/identity/users/session-management/) for the policy. 6. Configure as many [**Rules**](/cloudflare-one/policies/access/#rule-types) as needed. -7. Select **Add policy**. -8. Rearrange the rows in the policy table to match your desired [order of precedence](/cloudflare-one/policies/access/#order-of-execution). -9. Select **Save application**. +7. (Optional) Configure additional settings for users who match this policy: + - [Isolate application](/cloudflare-one/policies/access/isolate-application/). + - [Purpose justificaton](/cloudflare-one/policies/access/require-purpose-justification/) + - [Temporary authentication](/cloudflare-one/policies/access/temporary-auth/) +8. Select **Save**. -Your new policy is now in effect. +You can now add this policy to an [Access application](/cloudflare-one/applications/). ## Edit a policy -To make changes to an existing policy: +To make changes to an existing Access policy: -1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. -2. Locate the application for which you want to change the policies and select **Edit**. You will see a list of existing policies. -3. Locate the policy you want to update and select **Edit**. -4. Once you have made the necessary changes, select **Save policy**. -5. Select **Save application**. +1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Policies**. +2. Locate the policy you want to update and select **Configure**. +3. Once you have made the necessary changes, select **Save**. -The updated policy is now in effect. +The updated policy is now in effect for all associated Access applications. ## Delete a policy -To delete an Access policy: +To delete a reusable Access policy: -1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. -2. Locate the application for which you want to delete the policy and select **Edit**. You will see a list of existing policies. -3. Locate the policy you want to delete and select **Delete**. +1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Policies** and locate the policy you want to delete. +2. If the policy is used by an application, remove the policy from all associated applications. +3. Select **Delete**. 4. A pop-up message will ask you to confirm your decision to delete the policy. Select **Delete**. -5. Select **Save application**. - -Your policy has now been deleted. ## Test your policies @@ -55,12 +54,37 @@ You can test your policies against an existing user identity to see if they woul To check if a user has access to an application: 1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. -2. Locate the application you want to test and select **Edit**. -3. Select **Test your policies**. -4. Enter the user's email address and select **Check user**. +2. Locate the application you want to test and select **Configure**. +3. Go to the **Policies** tab and select **Test policies**. +4. Enter the user's email address and select **Test policies**. The policy tester reports the following information: * Whether the user is allowed or denied access to the application based on all configured policies. * The user's identity from their most recent Access login attempt. * Whether the user matches individual Allow, Block, or Bypass policies. + +## Legacy policies + +Legacy policies are scoped to a specific application and cannot be added to newly created Access applications. + +### Migrate to reusable policies + +To migrate legacy policies to reusable policies: + +1. [Create a reusable policy](#create-a-policy) that will replace the legacy policy. +2. Go to the Access application associated with the legacy policy. +3. Add the reusable policy to the application and remove the legacy policy. +4. Repeat these steps for each legacy policy. If you have duplicate legacy policies, you can replace them with a single reuseable policy. + +### Convert a legacy policy + +You can use the API to convert a legacy policy into a reusable policy. To convert a legacy policy, make a `PUT` request with an empty request body: + +```bash +curl --request PUT \ +https://api.cloudflare.com/client/v4/accounts/{account_id}/access/apps/{app_id}/policies/{policy_id}/make_reusable \ +--header "Authorization: Bearer " +``` + +The policy is now removed from the applications endpoint (`/access/apps/{app_id}/policies`) and managed using the [reusable policies endpoints](/api/resources/zero_trust/subresources/access/subresources/policies/)(`/access/policies/{policy_id}`). \ No newline at end of file diff --git a/src/content/docs/cloudflare-one/policies/access/require-purpose-justification.mdx b/src/content/docs/cloudflare-one/policies/access/require-purpose-justification.mdx index f3841f958803ff..6da5c3eab79857 100644 --- a/src/content/docs/cloudflare-one/policies/access/require-purpose-justification.mdx +++ b/src/content/docs/cloudflare-one/policies/access/require-purpose-justification.mdx @@ -2,7 +2,7 @@ pcx_content_type: how-to title: Require Purpose Justification sidebar: - order: 2 + order: 3 head: - tag: title content: Require Purpose Justification after login diff --git a/src/content/docs/cloudflare-one/policies/browser-isolation/known-limitations.mdx b/src/content/docs/cloudflare-one/policies/browser-isolation/known-limitations.mdx index ec372506aec1b3..978942c4181315 100644 --- a/src/content/docs/cloudflare-one/policies/browser-isolation/known-limitations.mdx +++ b/src/content/docs/cloudflare-one/policies/browser-isolation/known-limitations.mdx @@ -79,7 +79,7 @@ IdP sessions are not shared between the non-isolated IdP and the Clientless Web #### Add the application to Access -Configure a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) in Cloudflare Access and [enable browser isolation](/cloudflare-one/policies/access/isolate-application/) in the application settings. +Configure a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) in Cloudflare Access and [enable browser isolation](/cloudflare-one/policies/access/isolate-application/) in the application settings. #### Isolate both identity provider and service provider diff --git a/src/content/docs/cloudflare-one/policies/gateway/identity-selectors.mdx b/src/content/docs/cloudflare-one/policies/gateway/identity-selectors.mdx index 22057af7c6c3e6..a656f174f6687a 100644 --- a/src/content/docs/cloudflare-one/policies/gateway/identity-selectors.mdx +++ b/src/content/docs/cloudflare-one/policies/gateway/identity-selectors.mdx @@ -80,9 +80,9 @@ Use this selector to create identity-based Gateway rules based on an IdP usernam | --------- | ------------------------------ | | User Name | `identity.name == "user-name"` | -:::note[Gateway groups vs. Access groups] +:::note[Gateway groups vs. Access rule groups] -In Gateway, a **User Group** refers to a group in your IdP (for example, an Okta group). Gateway does not currently support applying DNS, HTTP, and Network policies to [Access groups](/cloudflare-one/identity/users/groups/). This is because Access groups may include criteria not available through the IdP, such as device location or IP address. +In Gateway, a **User Group** refers to a group in your IdP (for example, an Okta group). Gateway does not currently support applying DNS, HTTP, and Network policies to [Access rule groups](/cloudflare-one/policies/access/groups/). This is because Access rule groups may include criteria not available through the IdP, such as device location or IP address. ::: diff --git a/src/content/docs/cloudflare-one/policies/gateway/network-policies/index.mdx b/src/content/docs/cloudflare-one/policies/gateway/network-policies/index.mdx index e8df7923686b95..07fbd5042401d1 100644 --- a/src/content/docs/cloudflare-one/policies/gateway/network-policies/index.mdx +++ b/src/content/docs/cloudflare-one/policies/gateway/network-policies/index.mdx @@ -38,6 +38,7 @@ API value: `allow` **Traffic** +- [All Access Private Apps](#all-access-private-apps) - [Application](#application) - [Content Categories](#content-categories) - [Destination Continent IP Geolocation](#destination-continent) @@ -228,6 +229,14 @@ Gateway will only log successful override connections in your [network logs](/cl Gateway matches network traffic against the following selectors, or criteria. +### All Access Private Apps + +All destination IPs and hostnames associated with an [Access self-hosted private application](/cloudflare-one/applications/non-http/self-hosted-private-app/#modify-order-of-precedence-in-gateway). + +| UI name | API example | +| ----------- | -------------------------- | +| All Access Private Apps | `access.private_app` | + ### Application diff --git a/src/content/docs/cloudflare-one/tutorials/entra-id-conditional-access.mdx b/src/content/docs/cloudflare-one/tutorials/entra-id-conditional-access.mdx index 313c628889baa7..3de51e610b35e8 100644 --- a/src/content/docs/cloudflare-one/tutorials/entra-id-conditional-access.mdx +++ b/src/content/docs/cloudflare-one/tutorials/entra-id-conditional-access.mdx @@ -62,17 +62,25 @@ To enforce your Conditional Access policies on a Cloudflare Access application: 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. -2. Create a new [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-apps/). +2. Select **Add an application**. -3. In **Application domain**, enter the target URL of the protected application. +3. Select **Self-hosted**. -4. For **Identity providers**, select your Microsoft Entra ID integration. +4. Enter any name for the application. -5. Finally, create an [Access policy](/cloudflare-one/policies/access/) using the _Azure AD - Auth context_ selector. For example: +5. Select **Add public hostname** and enter the target URL of the protected application. + +6. Select **Create new policy** and build an [Access policy](/cloudflare-one/policies/access/) using the _Azure AD - Auth context_ selector. For example: | Action | Rule type | Selector | Value | | ------ | --------- | ----------------------- | --------------------------- | | Allow | Include | Emails ending in | `@example.com` | | | Require | Azure AD - Auth context | `Require compliant devices` | +7. Add this policy to your application configuration. + +8. For **Identity providers**, select your Microsoft Entra ID integration. + +9. Follow the remaining [self-hosted application creation steps](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to publish the application. + Users will only be allowed access if they pass the Microsoft Entra ID Conditional Access policies associated with this authentication context. diff --git a/src/content/docs/cloudflare-one/tutorials/extend-sso-with-workers.mdx b/src/content/docs/cloudflare-one/tutorials/extend-sso-with-workers.mdx index aed42e58bed72c..0e9e33d380cc27 100644 --- a/src/content/docs/cloudflare-one/tutorials/extend-sso-with-workers.mdx +++ b/src/content/docs/cloudflare-one/tutorials/extend-sso-with-workers.mdx @@ -33,7 +33,7 @@ This approach allows you to: ## Before you begin -- Add a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) to Cloudflare Access. +- Add a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to Cloudflare Access. - Enable the [Disk encryption](/cloudflare-one/identity/devices/warp-client-checks/disk-encryption/) and [Firewall](/cloudflare-one/identity/devices/warp-client-checks/firewall/) device posture checks. - Install [Wrangler](/workers/wrangler/install-and-update/) on your local machine. diff --git a/src/content/docs/cloudflare-one/tutorials/fastapi.mdx b/src/content/docs/cloudflare-one/tutorials/fastapi.mdx index 939391fcbde052..d78f234b0a944c 100644 --- a/src/content/docs/cloudflare-one/tutorials/fastapi.mdx +++ b/src/content/docs/cloudflare-one/tutorials/fastapi.mdx @@ -14,7 +14,7 @@ This tutorial covers how to validate that the [Access JWT](/cloudflare-one/ident ## Prerequisites -* A [self-hosted Access application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) for your FastAPI app +* A [self-hosted Access application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) for your FastAPI app * The [AUD tag](/cloudflare-one/identity/authorization-cookie/validating-json/#get-your-aud-tag) for your Access application ## 1. Create a validation function diff --git a/src/content/docs/cloudflare-one/tutorials/kubectl.mdx b/src/content/docs/cloudflare-one/tutorials/kubectl.mdx index da1a22c718de39..f44ceed780499a 100644 --- a/src/content/docs/cloudflare-one/tutorials/kubectl.mdx +++ b/src/content/docs/cloudflare-one/tutorials/kubectl.mdx @@ -25,16 +25,13 @@ You can connect to machines over `kubectl` using Cloudflare's Zero Trust platfor ## Create a Zero Trust policy -1. To create a new application, go to Zero Trust. From the sidebar, select the **Applications** page. Select **Add an application**. - ![Location of 'Add an application' button above Application list](~/assets/images/cloudflare-one/zero-trust-security/ssh/app-list.png) - -2. On the next page, choose **Self-hosted**. - -3. Within **Application Domain**, input a subdomain. This will be the hostname where your application will be available to users. - -4. Create rules to control who can reach the application. - -5. To save the policy, select **Save**. You can edit the policy later to change allowed users or authentication providers. +1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. +2. Select **Add an application**. +3. Select **Self-hosted**. +4. Enter a name for your Access application. +5. Select **Add public hostname** and input a subdomain. This will be the hostname where your application will be available to users. +6. [Create a new policy](/cloudflare-one/policies/access/policy-management/) to control who can reach the application, or select existing policies. +7. Follow the remaining [self-hosted application creation steps](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to publish the application. ## Install `cloudflared` diff --git a/src/content/docs/cloudflare-one/tutorials/mongodb-tunnel.mdx b/src/content/docs/cloudflare-one/tutorials/mongodb-tunnel.mdx index 7222d5b60a292f..505d0e204901f6 100644 --- a/src/content/docs/cloudflare-one/tutorials/mongodb-tunnel.mdx +++ b/src/content/docs/cloudflare-one/tutorials/mongodb-tunnel.mdx @@ -29,21 +29,19 @@ In this tutorial, a client running `cloudflared` connects over SSH to a MongoDB You can build a rule in Cloudflare Access to control who can connect to your MongoDB deployment. Cloudflare Access rules are built around a hostname; even though this deployment will be accessible over SSH, the resource will be represented in Cloudflare as a hostname. For example, if you have the website `app.com` in your Cloudflare account, you can build a rule to secure `mongodb.app.com`. -1. Follow [these instructions](/cloudflare-one/setup/) to set up Cloudflare Access in your account. +1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. -2. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. +2. Select **Add an application**. -3. Select **Add an application** and choose `Self-hosted`. +3. Select **Self-hosted**. -4. Create an application for a subdomain where users will connect to your deployment. Select **Next**. +4. Enter any name for the application. - ![MongoDB screen that shows how to add an application](~/assets/images/cloudflare-one/secure-origin-connections/mongodb-tunnel/add-app.png) +5. Select **Add public hostname** and enter the subdomain where users will connect to your deployment (for example, `mongodb.app.com`). -5. Build a rule to determine who can reach the deployment. You can build a rule that allows anyone in your organization to connect or you can build more granular rules based on signals like identity provider groups, [multifactor method](/cloudflare-one/tutorials/okta-u2f/), or [country](/cloudflare-one/identity/users/groups/). +6. Add [Access policies](/cloudflare-one/policies/access/) to control who can reach the deployment. You can build a policy that allows anyone in your organization to connect or you can build more granular policies based on signals like identity provider groups, [multifactor method](/cloudflare-one/tutorials/okta-u2f/), or [country](/cloudflare-one/policies/access/groups/). - ![MongoDB screen that shows how to configure a rule](~/assets/images/cloudflare-one/secure-origin-connections/mongodb-tunnel/add-rules.png) - -6. Select **Next** again and add the application. +7. Follow the remaining [self-hosted application creation steps](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to publish the application. ## Configure the Kubernetes deployment diff --git a/src/content/docs/cloudflare-one/tutorials/s3-buckets.mdx b/src/content/docs/cloudflare-one/tutorials/s3-buckets.mdx index 1a334872bc217c..24f8e4a90d471f 100644 --- a/src/content/docs/cloudflare-one/tutorials/s3-buckets.mdx +++ b/src/content/docs/cloudflare-one/tutorials/s3-buckets.mdx @@ -106,15 +106,13 @@ Your Cloudflare Tunnel will terminate at the AWS VPC using your public hostname. ### 5. Restrict S3 access with an Access policy -1. Go to **Access** > **Applications**. Select **Add an application**. -2. Select **Self-hosted**. -3. Enter a name for the application. -4. In **Application Domain**, enter the public hostname used by your Tunnel. For example, `s3-bucket..com`. -5. (Optional) Create a [service token](/cloudflare-one/identity/service-tokens/) to automatically authenticate access to your S3 bucket. -6. Configure your application, then select **Next**. -7. Add [Access policies](/cloudflare-one/policies/access/) to determine which users and applications may access your bucket. -8. Configure the settings per your organization's requirements. -9. Select **Add application**. +1. Go to **Access** > **Applications**. +2. Select **Add an application**. +3. Select **Self-hosted**. +4. Enter a name for the application. +5. Select **Add public hostname** and enter the public hostname used by your Tunnel. For example, `s3-bucket..com`. +6. Add [Access policies](/cloudflare-one/policies/access/) to determine which users and applications may access your bucket. You can optionally create a [service token](/cloudflare-one/identity/service-tokens/) policy to automatically authenticate access to your S3 bucket. +7. Follow the remaining [self-hosted application creation steps](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to publish the application. Users and applications that successfully authenticate via Cloudflare Access can access your S3 bucket at `https://s3-bucket..com`. diff --git a/src/content/docs/cloudflare-one/tutorials/vnc-client-in-browser.mdx b/src/content/docs/cloudflare-one/tutorials/vnc-client-in-browser.mdx index ee60192de54823..37ad5aa5b2bf9b 100644 --- a/src/content/docs/cloudflare-one/tutorials/vnc-client-in-browser.mdx +++ b/src/content/docs/cloudflare-one/tutorials/vnc-client-in-browser.mdx @@ -145,22 +145,22 @@ The last step is to create a Zero Trust application to run your VNC server in th 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. -2. Select **Add an application** and choose **Self-hosted**. +2. Select **Add an application**. -3. Name the application and set the domain to which you would like to expose the VNC server. +3. Select **Self-hosted**. - ![Example domain name input for VNC application](~/assets/images/cloudflare-one/zero-trust-security/vnc-client-in-browser/vnc-domain-application.png) +4. Enter any name for the application. -4. Add an Allow or Block policy. In this example, we are only allowing users with emails ending in `@example.com`. +5. Select **Add public hostname** and set the domain to which you would like to expose the VNC server. - ![Example Zero Trust policy input for VNC application](~/assets/images/cloudflare-one/zero-trust-security/vnc-client-in-browser/vnc-policy.png) +6. In **Access policies**, add an Allow or Block policy. For example policies, refer to the [Access policies documentation](/cloudflare-one/policies/access/#allow). :::note Service Auth and Bypass policies are not supported for browser-based VNC applications. ::: -5. In **Additional settings**, set **Browser rendering** to _VNC_. +7. In **Advanced settings**, set **Browser rendering** to _VNC_. Users will see a login screen with your configured identity providers. After successful authentication, they may be prompted to enter the VNC server's password. diff --git a/src/content/docs/fundamentals/basic-tasks/maintenance-mode.mdx b/src/content/docs/fundamentals/basic-tasks/maintenance-mode.mdx index 091ce5ce08b652..7944d863acfe5d 100644 --- a/src/content/docs/fundamentals/basic-tasks/maintenance-mode.mdx +++ b/src/content/docs/fundamentals/basic-tasks/maintenance-mode.mdx @@ -24,7 +24,7 @@ Certain customization and queue options depend on your [plan](/waiting-room/plan ### All plans -Users on all plans can [create an Access application](/cloudflare-one/applications/configure-apps/self-hosted-apps/). Make sure to limit your [Access policy](/cloudflare-one/policies/access/policy-management/#create-a-policy) to only include yourself and any collaborators. +Users on all plans can [create an Access application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/). Make sure to limit your [Access policy](/cloudflare-one/policies/access/policy-management/#create-a-policy) to only include yourself and any collaborators. If needed, you can also further [customize the login page](/cloudflare-one/applications/login-page). diff --git a/src/content/docs/hyperdrive/configuration/connect-to-private-database.mdx b/src/content/docs/hyperdrive/configuration/connect-to-private-database.mdx index 151b2d1950a7a7..fc34cd4eec2e6a 100644 --- a/src/content/docs/hyperdrive/configuration/connect-to-private-database.mdx +++ b/src/content/docs/hyperdrive/configuration/connect-to-private-database.mdx @@ -82,25 +82,33 @@ The service token will be used to restrict requests to the tunnel, and is needed 3. Select **Self-hosted**. -4. In **Application Configuration** > **Application name**, enter any name for the application. +4. Enter any name for the application. -5. In **Application Configuration** > **Session Duration**, select `No duration, expires immediately`. +5. In **Session Duration**, select `No duration, expires immediately`. -6. In **Application Configuration** > **Application domain**, enter the subdomain and domain that was previously set for the tunnel application. +6. Select **Add public hostname**. and enter the subdomain and domain that was previously set for the tunnel application. -7. In **Application Appearance**, disable the `Enable App in App Launcher` setting. +7. Select **Create new policy**. -8. In **Identity providers**, disable the `Accept all available identity providers` setting and select `Deselect all` identity providers. +8. Enter a **Policy name** and set the **Action** to _Service Auth_. -9. Select **Next**. +9. Create an **Include** rule. Specify a **Selector** of _Service Token_ and the **Value** of the service token you created in step [2. Create a service token](#2-create-a-service-token). -10. Enter a name in the **Policy name** and set the **Action** to `Service Auth`. +10. Save the policy. -11. In **Configure rules**, create an **Include** rule. Specify a **Selector** of `Service Token` and the **Value** of the service token you created in step [2. Create a service token](#2-create-a-service-token). +11. Go back to the application configuration and add the newly created Access policy. -12. Select **Next**. +12. In **Login methods**, turn off _Accept all available identity providers_ and clear all identity providers. -13. Select **Add application** to create the Access application. +13. Select **Next**. + +14. In **Application Appearance**, turn off **Show application in App Launcher**. + +15. Select **Next**. + +16. Select **Next**. + +17. Save the application. ## 4. Create a Hyperdrive configuration diff --git a/src/content/docs/learning-paths/mtls/mtls-cloudflare-access/index.mdx b/src/content/docs/learning-paths/mtls/mtls-cloudflare-access/index.mdx index d377e73dc295a3..6b227eceee6e51 100644 --- a/src/content/docs/learning-paths/mtls/mtls-cloudflare-access/index.mdx +++ b/src/content/docs/learning-paths/mtls/mtls-cloudflare-access/index.mdx @@ -114,7 +114,7 @@ Additionally, authenticated requests also send the `Cf-Access-Jwt-Assertion\` JW ## 4. Create the self-hosted applications -Finally, the hostname you want to protect with mTLS needs to be added as a [self-hosted app](/cloudflare-one/applications/configure-apps/self-hosted-apps/) in Cloudflare Access, defining an [Access Policy](/cloudflare-one/policies/access/) which uses the action [Service Auth](/cloudflare-one/policies/access/#service-auth) and the Selector _"Valid Certificate"_, or simply requiring an [IdP](/cloudflare-one/identity/idp-integration/) authentication. You can also take advantage of extra requirements, such as the "Common Name" (CN), which expects the indicated hostname, and more [Selectors](/cloudflare-one/policies/access/#selectors). Alternatively, one can also [extend ZTNA with external authorization and serverless computing](/reference-architecture/diagrams/sase/augment-access-with-serverless/). +Finally, the hostname you want to protect with mTLS needs to be added as a [self-hosted app](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) in Cloudflare Access, defining an [Access Policy](/cloudflare-one/policies/access/) which uses the action [Service Auth](/cloudflare-one/policies/access/#service-auth) and the Selector _"Valid Certificate"_, or simply requiring an [IdP](/cloudflare-one/identity/idp-integration/) authentication. You can also take advantage of extra requirements, such as the "Common Name" (CN), which expects the indicated hostname, and more [Selectors](/cloudflare-one/policies/access/#selectors). Alternatively, one can also [extend ZTNA with external authorization and serverless computing](/reference-architecture/diagrams/sase/augment-access-with-serverless/). ## Demo diff --git a/src/content/docs/learning-paths/zero-trust-web-access/access-application/best-practices.mdx b/src/content/docs/learning-paths/zero-trust-web-access/access-application/best-practices.mdx index 88e47ccf4ca234..7ee2917be77e92 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/access-application/best-practices.mdx +++ b/src/content/docs/learning-paths/zero-trust-web-access/access-application/best-practices.mdx @@ -10,11 +10,9 @@ import { Render } from "~/components" Learn best practices for building scalable Access applications and policies. -## Use Access groups +## Create reusable policy components -Access groups are reusable sets of rules that you can quickly apply across multiple applications. This could be a definition such as "corporate users", which has both device posture check requirements and specific emails, or just “developers”, which references a group in your identity provider. If you have many applications that will need identical policy structure, we recommend building an Access group and referencing it across multiple applications. - - +If you have many policies that contain duplicate rules, we recommend [building a rule group](/cloudflare-one/policies/access/groups/) and referencing it across multiple policies. For example, you could define a rule group for "corporate users", which has both device posture check requirements and specific emails, or just “developers”, which references a group in your identity provider. ## Define your domain structure diff --git a/src/content/docs/learning-paths/zero-trust-web-access/access-application/create-access-app.mdx b/src/content/docs/learning-paths/zero-trust-web-access/access-application/create-access-app.mdx index 41e0e91133da89..9584d8f4e84973 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/access-application/create-access-app.mdx +++ b/src/content/docs/learning-paths/zero-trust-web-access/access-application/create-access-app.mdx @@ -8,19 +8,12 @@ sidebar: import { Render } from "~/components" - +Cloudflare Access allows you to securely publish internal tools and applications to the Internet by providing an authentication layer between the end user and your origin server. You can use signals from your existing identity providers (IdPs), device posture providers, and [other rules](/cloudflare-one/policies/access/#selectors) to control who can access your application. + Each application can have multiple policies with different constraints depending on what user group is accessing the application. For example, you can create one policy that requires corporate users to present specific device posture checks or mutual TLS authentication events, and a second policy for contractors which does not require these attributes. ## Add your application to Access -## Add an Access policy - - - -## (Optional) Configure advanced settings - - - When users go to the application, they will be prompted to login with your identity provider. diff --git a/src/content/docs/learning-paths/zero-trust-web-access/access-application/index.mdx b/src/content/docs/learning-paths/zero-trust-web-access/access-application/index.mdx index c8253294418a3a..2030f09a16b98e 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/access-application/index.mdx +++ b/src/content/docs/learning-paths/zero-trust-web-access/access-application/index.mdx @@ -14,5 +14,5 @@ By the end of this module, you will be able to: * Add your application to Cloudflare Access. * Create an Access policy. -* Define an Access group. +* Design reusable policies. * Design a domain structure for your applications. diff --git a/src/content/docs/pages/how-to/preview-with-cloudflare-tunnel.mdx b/src/content/docs/pages/how-to/preview-with-cloudflare-tunnel.mdx index 16a1bd8fbdc26c..20b4f1714fde14 100644 --- a/src/content/docs/pages/how-to/preview-with-cloudflare-tunnel.mdx +++ b/src/content/docs/pages/how-to/preview-with-cloudflare-tunnel.mdx @@ -58,4 +58,4 @@ In this example, the randomly-generated URL `https://seasonal-deck-organisms-sf. Cloudflare Tunnel can be configured in a variety of ways and can be used beyond providing access to your in-development applications. For example, you can provide `cloudflared` with a [configuration file](/cloudflare-one/connections/connect-networks/configure-tunnels/local-management/configuration-file/) to add more complex routing and tunnel setups that go beyond a simple `--url` flag. You can also [attach a Cloudflare DNS record](/cloudflare-one/connections/connect-networks/routing-to-tunnel/dns/) to a domain or subdomain for an easily accessible, long-lived tunnel to your local machine. -Finally, by incorporating Cloudflare Access, you can provide [secure access to your tunnels](/cloudflare-one/applications/configure-apps/self-hosted-apps/) without exposing your entire server, or compromising on security. Refer to the [Cloudflare for Teams documentation](/cloudflare-one/) to learn more about what you can do with Cloudflare's entire suite of Zero Trust tools. +Finally, by incorporating Cloudflare Access, you can provide [secure access to your tunnels](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) without exposing your entire server, or compromising on security. Refer to the [Cloudflare for Teams documentation](/cloudflare-one/) to learn more about what you can do with Cloudflare's entire suite of Zero Trust tools. diff --git a/src/content/docs/r2/tutorials/cloudflare-access.mdx b/src/content/docs/r2/tutorials/cloudflare-access.mdx index 597c2a93bea690..bec063bab4bb9d 100644 --- a/src/content/docs/r2/tutorials/cloudflare-access.mdx +++ b/src/content/docs/r2/tutorials/cloudflare-access.mdx @@ -35,22 +35,20 @@ Within the **Zero Trust** section of the Cloudflare Dashboard, you will need to If you have not configured Cloudflare Access before, we recommend: * Configuring an [identity provider](/cloudflare-one/identity/) first to enable Access to use your organization's single-sign on (SSO) provider as an authentication method. -* Creating an [Access group](/cloudflare-one/identity/users/groups/) that defines which users or groups within your organization can access specific resources. To create an Access application for your R2 bucket: 1. Go to [**Access**](https://one.dash.cloudflare.com/?to=/:account/access/apps) and select **Add an application** -2. Select **Self-hosted** -3. Enter an **Application name** -4. Enter the **Application domain**. The **Domain** must be a domain hosted on Cloudflare, and the **Subdomain** part of the custom domain you will connect to your R2 bucket. For example, if you want to serve files from `behind-access.example.com` and `example.com` is a domain within your Cloudflare account, then enter `behind-access` in the subdomain field and select `example.com` from the **Domain** list. -5. (Optional) Configure the block page policy. This can be changed later. -6. Configure the **Identity providers** that will be used to protect this domain using Access. -7. Click **Next** -8. Enter a **Policy name** and an **Action**. This should be **Allow**, and will enable the group(s) you select to access objects within the bucket behind this Access application. -9. To **Assign a group** (or groups) and allow access to your bucket, select one or more groups. If you have not created any groups, you will [need to do this first](/cloudflare-one/identity/users/groups/). You should **ensure that this group only contains the users within your organization that need access to this R2 bucket**. -10. Click **Next** and then **Add an application**. - -Review the [Cloudflare Access documentation](/cloudflare-one/applications/configure-apps/self-hosted-apps/) to understand how to configure additional Access application options. +2. Select **Self-hosted**. +3. Enter an **Application name**. +4. Select **Add a public hostname** and enter the application domain. The **Domain** must be a domain hosted on Cloudflare, and the **Subdomain** part of the custom domain you will connect to your R2 bucket. For example, if you want to serve files from `behind-access.example.com` and `example.com` is a domain within your Cloudflare account, then enter `behind-access` in the subdomain field and select `example.com` from the **Domain** list. +5. Add [Access policies](/cloudflare-one/policies/access/) to control who can connect to your application. This should be an **Allow** policy so that users can access objects within the bucket behind this Access application. + + :::note + Ensure that your policies only allow the users within your organization that need access to this R2 bucket. + ::: + +6. Follow the remaining [self-hosted application creation steps](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to publish the application. ## 3. Connect a custom domain @@ -70,9 +68,9 @@ You will need to [connect a custom domain](/r2/buckets/public-buckets/#connect-a Visit the custom domain you connected to your R2 bucket, which should present a Cloudflare Access authentication page with your selected identity provider(s) and/or authentication methods. -For example, if you connected Google and/or GitHub identity providers, you can log in with those providers. If the login is successful and your account is a member of the [Access group](/cloudflare-one/identity/users/groups/) you associated with the Access application you created in this guide, you will be able to access (read/download) objects within the R2 bucket. +For example, if you connected Google and/or GitHub identity providers, you can log in with those providers. If the login is successful and you pass the Access policies configured in this guide, you will be able to access (read/download) objects within the R2 bucket. -If you cannot authenticate or receive a block page after authenticating, check that you have an [Access policy](/cloudflare-one/applications/configure-apps/self-hosted-apps/#2-add-an-access-policy) configured within your Access application that explicitly allows the group your user account is associated with. +If you cannot authenticate or receive a block page after authenticating, check that you have an [Access policy](/cloudflare-one/applications/configure-apps/self-hosted-public-app/#2-add-an-access-policy) configured within your Access application that explicitly allows the group your user account is associated with. ## Next steps diff --git a/src/content/docs/reference-architecture/design-guides/designing-ztna-access-policies.mdx b/src/content/docs/reference-architecture/design-guides/designing-ztna-access-policies.mdx index 6def3a0239bc23..23f79149099320 100644 --- a/src/content/docs/reference-architecture/design-guides/designing-ztna-access-policies.mdx +++ b/src/content/docs/reference-architecture/design-guides/designing-ztna-access-policies.mdx @@ -169,7 +169,7 @@ There are many different [types of selectors](/cloudflare-one/policies/access/#s You can configure this control by enabling the "gateway" device posture check and then requiring "gateway" in your application policies. Requiring "gateway" is more flexible than relying solely on the device agent because users can also on-ramp from Browser Isolation or a Magic WAN-connected site, both of which provide traffic logging and filtering. Additionally, when using the device agent, this allows you to guarantee that a user is coming from a compliant device that has passed a set of device posture checks. - Requiring the gateway is enforced continuously for [self-hosted applications](/cloudflare-one/applications/configure-apps/self-hosted-apps/). For SaaS apps, it is only enforced at the time of login. However, a dedicated egress IP can be leveraged in tandem to enforce that traffic always goes via Cloudflare Gateway. + Requiring the gateway is enforced continuously for [self-hosted applications](/cloudflare-one/applications/configure-apps/self-hosted-public-app/). For SaaS apps, it is only enforced at the time of login. However, a dedicated egress IP can be leveraged in tandem to enforce that traffic always goes via Cloudflare Gateway. - **Does the user belong to an existing group, or have specific identity attributes?** If your IdP supports SCIM, group membership information can be imported into Cloudflare, where it can be used in policies. Group information can also come from the SAML or OAuth data sent as part of authentication. In fact, when OIDC or SAML is used and claims are sent, they can be used in a policy. So if your users authenticate to your IDP using SAML, and the resulting token contains their "role," you can query that value in the rule. @@ -237,7 +237,7 @@ Add an additional layer of access control by requiring users to obtain "temporar ### Access Groups -One of the most important parts of defining ZTNA policies is to leverage reusable elements called [Access Groups](/cloudflare-one/identity/users/groups/). Each access group uses the same rules we've just described to define users, traffic or devices. These groups can then be used across many policies to allow, deny, bypass, or isolate access to an application. +One of the most important parts of defining ZTNA policies is to leverage reusable elements called [Access Groups](/cloudflare-one/policies/access/groups/). Each access group uses the same rules we've just described to define users, traffic or devices. These groups can then be used across many policies to allow, deny, bypass, or isolate access to an application. For example, you can define "Employees" once as an Access Group, and then use that in every application policy where you want to refer to employees. Updates to this Access Group would then be reflected in every policy. This is also a good way to include nested logic (for example, users with a Linux device and has antivirus software enabled) diff --git a/src/content/docs/reference-architecture/design-guides/network-vpn-migration.mdx b/src/content/docs/reference-architecture/design-guides/network-vpn-migration.mdx index 007708cac5a672..c1d5ed4939f759 100644 --- a/src/content/docs/reference-architecture/design-guides/network-vpn-migration.mdx +++ b/src/content/docs/reference-architecture/design-guides/network-vpn-migration.mdx @@ -204,7 +204,7 @@ In the example below, `erp.example.com` is added as [Public Hostname](/cloudflar ![Adding a public hostname to a tunnel for clientless access to internal applications.](~/assets/images/reference-architecture/design-guide-network-vpn-migr/clientless-access.svg "Figure 7: Adding a public hostname to a tunnel for clientless access to internal applications.") -Not all applications will be suitable for this type of access. Only HTTP(S) applications or [applications that can be rendered in the browser](/cloudflare-one/applications/non-http/) such as SSH and VNC are supported. To learn more about such a deployment and additional advanced options such cookie settings, browser isolation and using the Access token in your application for authentication, see the [self-hosted application documentation](/cloudflare-one/applications/configure-apps/self-hosted-apps/). +Not all applications will be suitable for this type of access. Only HTTP(S) applications or [applications that can be rendered in the browser](/cloudflare-one/applications/non-http/) such as SSH and VNC are supported. To learn more about such a deployment and additional advanced options such cookie settings, browser isolation and using the Access token in your application for authentication, see the [self-hosted application documentation](/cloudflare-one/applications/configure-apps/self-hosted-public-app/). ## Summary diff --git a/src/content/docs/security-center/security-insights/index.mdx b/src/content/docs/security-center/security-insights/index.mdx index b799b3b8462d05..2d7321ef6e99e0 100644 --- a/src/content/docs/security-center/security-insights/index.mdx +++ b/src/content/docs/security-center/security-insights/index.mdx @@ -40,7 +40,7 @@ Listed below are the specific insights currently available: | [Turn on JavaScript Detection](/bots/reference/javascript-detections/) | One or more of your Bot Management enabled zones does not have JavaScript Detection enabled, which is a critical part of our bot detection suite. | | [Unassigned Access seats](/cloudflare-one/) | We detect a Zero Trust subscription that is not configured yet. | | [Unauthenticated API endpoints detected](/api-shield/management-and-monitoring/endpoint-labels/#managed-labels) | None of the successful requests against API endpoints carried session identifiers. | -| [Unprotected Cloudflare Tunnels](/cloudflare-one/applications/configure-apps/self-hosted-apps/#4-connect-your-origin-to-cloudflare) | We detect an application that is served by a Cloudflare Tunnel but not protected by a corresponding Access policy. | +| [Unprotected Cloudflare Tunnels](/cloudflare-one/applications/configure-apps/self-hosted-public-app/#4-connect-your-origin-to-cloudflare) | We detect an application that is served by a Cloudflare Tunnel but not protected by a corresponding Access policy. | | [Unproxied `A` Records](/dns/manage-dns-records/reference/dns-record-types/#a-and-aaaa) | This DNS record is not proxied by Cloudflare. Cloudflare can not protect this origin because it is exposed to the public Internet. | | [Unproxied `AAAA` Records](/dns/manage-dns-records/reference/dns-record-types/#a-and-aaaa) | This DNS record is not proxied by Cloudflare. Cloudflare can not protect this origin because it is exposed to the public Internet. | | [Unproxied `CNAME` Records](/dns/manage-dns-records/reference/proxied-dns-records/#dns-only-records) | This DNS record is not proxied by Cloudflare. Cloudflare can not protect this origin because it is exposed to the public Internet. | diff --git a/src/content/docs/support/third-party-software/content-management-system-cms/improving-web-security-for-content-management-systems-like-wordpress.mdx b/src/content/docs/support/third-party-software/content-management-system-cms/improving-web-security-for-content-management-systems-like-wordpress.mdx index 3012c290176ff6..62ab3b818217ac 100644 --- a/src/content/docs/support/third-party-software/content-management-system-cms/improving-web-security-for-content-management-systems-like-wordpress.mdx +++ b/src/content/docs/support/third-party-software/content-management-system-cms/improving-web-security-for-content-management-systems-like-wordpress.mdx @@ -13,7 +13,7 @@ There are many Cloudflare features that can be used for preventing such attacks, ## Stage One: Improve Site Security -In this stage, you are reinforcing the zone’s security features, which may cause additional disruption to admin features until exceptions can be applied. For that reason, it’s recommended to make these changes with expected administrative downtime.  +In this stage, you are reinforcing the zone’s security features, which may cause additional disruption to admin features until exceptions can be applied. For that reason, it’s recommended to make these changes with expected administrative downtime. The following should be considered an overview of some recommended security actions, and not a comprehensive guide. Refer to the developer documentation for specific products or features for more information. @@ -83,7 +83,7 @@ Now that you’ve elevated your security to protect the publicly accessible part ### Zero Trust -[Zero Trust](https://www.cloudflare.com/plans/zero-trust-services/) Web Applications is the best way to limit access to your admin panel. You can restrict access based on user instead of device, and it allows for very granular control. Setup of a Self-hosted web application is very easy, for more information refer to the [Self-hosted applications](/cloudflare-one/applications/configure-apps/self-hosted-apps/) section of the Zero Trust developer documentation. +[Zero Trust](https://www.cloudflare.com/plans/zero-trust-services/) Web Applications is the best way to limit access to your admin panel. You can restrict access based on user instead of device, and it allows for very granular control. Setup of a Self-hosted web application is very easy, for more information refer to the [Self-hosted applications](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) section of the Zero Trust developer documentation. After configuring a web application, users will be required to authenticate in some way before they can access the restricted content. The default method is through email multifactor authentication: @@ -107,7 +107,7 @@ Do the following: ### Rate Limiting -Rate limiting rules can help protect your login page from an attacker trying to guess your account password with a [brute force attack](https://www.cloudflare.com/learning/bots/brute-force-attack/). You can define rate limits for requests matching an expression, as well as the action to perform when those rate limits are reached.  +Rate limiting rules can help protect your login page from an attacker trying to guess your account password with a [brute force attack](https://www.cloudflare.com/learning/bots/brute-force-attack/). You can define rate limits for requests matching an expression, as well as the action to perform when those rate limits are reached. Rate Limiting Rules are now available unmetered, on all plans. For more information, refer to the [developer documentation](/waf/rate-limiting-rules/). diff --git a/src/content/docs/workers/examples/basic-auth.mdx b/src/content/docs/workers/examples/basic-auth.mdx index 93303e801f4cf9..0648bc2ade5dd7 100644 --- a/src/content/docs/workers/examples/basic-auth.mdx +++ b/src/content/docs/workers/examples/basic-auth.mdx @@ -27,7 +27,7 @@ This example Worker makes use of the [Node.js Buffer API](/workers/runtime-apis/ :::caution[Caution when using in production] -This code is provided as a sample, and is not suitable for production use. Basic Authentication sends credentials unencrypted, and must be used with an HTTPS connection to be considered secure. For a production-ready authentication system, consider using [Cloudflare Access](https://developers.cloudflare.com/cloudflare-one/applications/configure-apps/self-hosted-apps/). +This code is provided as a sample, and is not suitable for production use. Basic Authentication sends credentials unencrypted, and must be used with an HTTPS connection to be considered secure. For a production-ready authentication system, consider using [Cloudflare Access](https://developers.cloudflare.com/cloudflare-one/applications/configure-apps/self-hosted-public-app/). ::: diff --git a/src/content/glossary/cloudflare-one.yaml b/src/content/glossary/cloudflare-one.yaml index b11998a8ca728a..e955a62da62abd 100644 --- a/src/content/glossary/cloudflare-one.yaml +++ b/src/content/glossary/cloudflare-one.yaml @@ -1,10 +1,6 @@ --- productName: Cloudflare One entries: - - term: Access group - general_definition: |- - a set of rules that can be configured once and then quickly applied across many Access applications. - - term: App Launcher general_definition: |- the App Launcher portal provides end users with a single dashboard to open applications secured by Cloudflare Zero Trust. @@ -147,6 +143,10 @@ entries: general_definition: |- Remote Desktop Protocol (RDP) allows remote desktop connections to a computer, often used on Windows and Mac operating systems. + - term: Rule group + general_definition: |- + a set of Access rules that can be configured once and then quickly applied across many Access policies. + - term: SafeSearch general_definition: |- SafeSearch is a feature of search engines that filters explicit or offensive content from search results. diff --git a/src/content/partials/cloudflare-one/access/access-block-page.mdx b/src/content/partials/cloudflare-one/access/access-block-page.mdx index 423d673815b1e9..29a9c277f4a93f 100644 --- a/src/content/partials/cloudflare-one/access/access-block-page.mdx +++ b/src/content/partials/cloudflare-one/access/access-block-page.mdx @@ -3,7 +3,7 @@ --- -Under **Block pages**, choose what end users will see when they are denied access to the application: +Under **Block page**, choose what end users will see when they are denied access to the application: * **Cloudflare default**: Reload the [login page](/cloudflare-one/applications/login-page/) and display a block message below the Cloudflare Access logo. The default message is `That account does not have access`, or you can enter a custom message. * **Redirect URL**: Redirect to the specified website. diff --git a/src/content/partials/cloudflare-one/access/access-choose-idps.mdx b/src/content/partials/cloudflare-one/access/access-choose-idps.mdx index 6ae9aee30fd0dd..bbed29249ff1e4 100644 --- a/src/content/partials/cloudflare-one/access/access-choose-idps.mdx +++ b/src/content/partials/cloudflare-one/access/access-choose-idps.mdx @@ -3,7 +3,7 @@ --- -Next, configure how users will authenticate: +Configure how users will authenticate: 1. Select the [**Identity providers**](/cloudflare-one/identity/idp-integration/) you want to enable for your application. diff --git a/src/content/partials/cloudflare-one/access/enable-isolation.mdx b/src/content/partials/cloudflare-one/access/enable-isolation.mdx index 1c4507bd6c7bfe..cc58c670e38631 100644 --- a/src/content/partials/cloudflare-one/access/enable-isolation.mdx +++ b/src/content/partials/cloudflare-one/access/enable-isolation.mdx @@ -8,7 +8,7 @@ import { Render } from "~/components" 3. Next, go to **Access** > **Applications**. -4. Choose a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) and select **Configure**. +4. Choose a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) and select **Configure**. 5. Choose an [Allow policy](/cloudflare-one/policies/access/) and select **Configure**. 6. Under **Additional settings**, turn on **Isolate application**. 7. Save the policy. diff --git a/src/content/partials/cloudflare-one/access/access-group.mdx b/src/content/partials/cloudflare-one/access/rule-group.mdx similarity index 88% rename from src/content/partials/cloudflare-one/access/access-group.mdx rename to src/content/partials/cloudflare-one/access/rule-group.mdx index 1e47c15d267b84..1224a4eb3def3d 100644 --- a/src/content/partials/cloudflare-one/access/access-group.mdx +++ b/src/content/partials/cloudflare-one/access/rule-group.mdx @@ -4,12 +4,12 @@ import { TabItem, Tabs } from "~/components"; -To create an Access group: +To create an Access rule group: -1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Access Groups**. -2. Select **Add a Group**. +1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Rule groups**. +2. Select **Add a group**. 3. Enter a name for the group (for example, `Lisbon-team`). 4. Specify as many rules as needed to define your user group. For example, the following rules define a team based in Lisbon, Portugal: @@ -54,4 +54,4 @@ curl https://api.cloudflare.com/client/v4/accounts/{account_id}/access/groups \ -You can now select this group in the Access policy builder. +You can now add this group to an Access policy using the _Rule groups_ selector. diff --git a/src/content/partials/cloudflare-one/access/self-hosted-app.mdx b/src/content/partials/cloudflare-one/access/self-hosted-app.mdx index c896653118d11e..7d11ef74287cf8 100644 --- a/src/content/partials/cloudflare-one/access/self-hosted-app.mdx +++ b/src/content/partials/cloudflare-one/access/self-hosted-app.mdx @@ -17,15 +17,32 @@ import { Render } from "~/components" Cloudflare checks every HTTP request to your application for a valid application token. If the user's application token (and global token) has expired, they will be prompted to reauthenticate with the IdP. For more information, refer to [Session management](/cloudflare-one/identity/users/session-management/). -6. In **Application domain**, enter the domains that will represent the application. +6. Select **Add public hostname**. - * Domains must belong to an active zone in your Cloudflare account. You can either select a domain from the dropdown or enter a [custom domain](/cloudflare-for-platforms/cloudflare-for-saas/security/secure-with-access/) that you control. - * You can use [wildcards](/cloudflare-one/policies/access/app-paths/) to protect multiple parts of an application that share a root path. +7. In the **Domain** dropdown, select the domain that will represent the application. Domains must belong to an active zone in your Cloudflare account. You can use [wildcards](/cloudflare-one/policies/access/app-paths/) to protect multiple parts of an application that share a root path. -7. (Optional) Configure [App Launcher settings](/cloudflare-one/applications/app-launcher/) for the application. + Alternatively, to use a [Cloudflare for SaaS custom hostname](/cloudflare-for-platforms/cloudflare-for-saas/security/secure-with-access/), set **Input method** to _Custom_ and enter your custom hostname. -8. +8. Add [Access policies](/cloudflare-one/policies/access/) to control who can connect to your application. All Access applications are deny by default -- a user must match an Allow policy before they are granted access. 9. 10. Select **Next**. + +11. (Optional) Configure [App Launcher settings](/cloudflare-one/applications/app-launcher/) for the application. + +12. + +13. Select **Next**. + +14. (Optional) Configure advanced settings for your application: + + - [**Cross-Origin Resource Sharing (CORS) settings**](/cloudflare-one/identity/authorization-cookie/cors/) + - [**Cookie settings**](/cloudflare-one/identity/authorization-cookie/#cookie-settings) + - **Browser rendering settings**: + - [Automatic `cloudflared` authentication](/cloudflare-one/applications/non-http/cloudflared-authentication/automatic-cloudflared-authentication/) + - [Browser rendering for SSH and VNC](/cloudflare-one/applications/non-http/browser-rendering/) + - **401 Response for Service Auth policies**: Return a `401` response code when a user (or machine) makes a request to the application without the correct [service token](/cloudflare-one/identity/service-tokens/). + +15. Select **Save**. + diff --git a/src/content/partials/cloudflare-one/access/self-hosted-intro.mdx b/src/content/partials/cloudflare-one/access/self-hosted-intro.mdx deleted file mode 100644 index b4fe988d48784f..00000000000000 --- a/src/content/partials/cloudflare-one/access/self-hosted-intro.mdx +++ /dev/null @@ -1,6 +0,0 @@ ---- -{} - ---- - -Cloudflare Access allows you to securely publish internal tools and applications to the Internet by providing an authentication layer between the end user and your origin server. You can use signals from your existing identity providers (IdPs), device posture providers, and [other rules](/cloudflare-one/policies/access/#selectors) to control who can access your application. diff --git a/src/content/partials/cloudflare-one/access/self-hosted-policy.mdx b/src/content/partials/cloudflare-one/access/self-hosted-policy.mdx deleted file mode 100644 index a46113c7dd3bb7..00000000000000 --- a/src/content/partials/cloudflare-one/access/self-hosted-policy.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -{} - ---- - -You can now configure an [Access policy](/cloudflare-one/policies/access/) to control who can connect to your application. - -1. Enter any name for your policy. - -2. Specify a policy [action](/cloudflare-one/policies/access/#actions). - -3. Assign [Access groups](/cloudflare-one/identity/users/groups/) to reuse existing rules, or create new rules. You can add as many include, exception, or require statements as needed. - -4. (Optional) Customize the login experience for users who match this policy: - - * [Purpose justification](/cloudflare-one/policies/access/require-purpose-justification/) - * [Temporary authentication](/cloudflare-one/policies/access/temporary-auth/) - -5. Select **Next**. diff --git a/src/content/partials/cloudflare-one/access/self-hosted-settings.mdx b/src/content/partials/cloudflare-one/access/self-hosted-settings.mdx deleted file mode 100644 index fd32963e1a2866..00000000000000 --- a/src/content/partials/cloudflare-one/access/self-hosted-settings.mdx +++ /dev/null @@ -1,13 +0,0 @@ ---- -{} - ---- - -You can configure the following advanced settings for your application: - -* [Cross-Origin Resource Sharing (CORS)](/cloudflare-one/identity/authorization-cookie/cors/) -* [Cookie settings](/cloudflare-one/identity/authorization-cookie/#cookie-settings) -* [Automatic `cloudflared` authentication](/cloudflare-one/applications/non-http/cloudflared-authentication/automatic-cloudflared-authentication/) -* [Browser rendering](/cloudflare-one/applications/non-http/browser-rendering/) - -To finish configuring the application, select **Add application**. diff --git a/src/content/partials/cloudflare-one/ssh/tunnel-public-hostname.mdx b/src/content/partials/cloudflare-one/ssh/tunnel-public-hostname.mdx index 53634e5e490628..ac1790edaa43f5 100644 --- a/src/content/partials/cloudflare-one/ssh/tunnel-public-hostname.mdx +++ b/src/content/partials/cloudflare-one/ssh/tunnel-public-hostname.mdx @@ -10,4 +10,4 @@ 4. Select **Save hostname**. -5. (Recommended) Add a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) to Cloudflare Access in order to manage access to your server. +5. (Recommended) Add a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to Cloudflare Access in order to manage access to your server. diff --git a/src/content/partials/cloudflare-one/tunnel/cloud-public-hostname.mdx b/src/content/partials/cloudflare-one/tunnel/cloud-public-hostname.mdx index a68d6363b28e07..e80fa2c455286f 100644 --- a/src/content/partials/cloudflare-one/tunnel/cloud-public-hostname.mdx +++ b/src/content/partials/cloudflare-one/tunnel/cloud-public-hostname.mdx @@ -10,4 +10,4 @@ 3. Select **Save hostname**. 4. To test, open a browser and go to `http://hellocloudflare..com`. You should see the **Hello Cloudflare!** test page. -You can optionally [create an Access application](/cloudflare-one/applications/configure-apps/self-hosted-apps/) to control who can access the service. +You can optionally [create an Access application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) to control who can access the service. diff --git a/src/content/partials/cloudflare-one/tunnel/enable-gateway-proxy.mdx b/src/content/partials/cloudflare-one/tunnel/enable-gateway-proxy.mdx index c59db0ea993b56..f707ab2794a744 100644 --- a/src/content/partials/cloudflare-one/tunnel/enable-gateway-proxy.mdx +++ b/src/content/partials/cloudflare-one/tunnel/enable-gateway-proxy.mdx @@ -8,41 +8,6 @@ import { Tabs, TabItem } from "~/components"; 2. In **Firewall**, turn on **Proxy**. 3. Select **TCP**. 4. (Recommended) To proxy traffic to internal DNS resolvers, select **UDP**. -5. (Recommended) To proxy traffic for diagnostic tools such as `ping` and `traceroute`, select **ICMP**. You may also need to update your system to allow ICMP traffic through `cloudflared`: - - - -1. Ensure that `ping_group_range` includes the Group ID (GID) of the user running `cloudflared`. - - 1. To get the Group ID of the user, run `id -g`. - 2. To verify the Group IDs that are allowed to use ICMP: - - ```sh - sudo sysctl net.ipv4.ping_group_range - ``` - - ```sh output - net.ipv4.ping_group_range= 0 10000 - ``` - - 3. Either add the user to a group within that range, or update the range to encompass a group the user is already in. To update `ping_group_range`: - - ```sh - echo 0 10001 | sudo tee /proc/sys/net/ipv4/ping_group_range - ``` - -2. If you are running multiple network interfaces (for example, `eth0` and `eth1`), configure `cloudflared` to use the external Internet-facing interface: - - ```sh - cloudflared tunnel run --icmpv4-src - ``` - - - -In your environment, modify the `ping_group_range` parameter to include the Group ID (GID) of the user running `cloudflared`. - -By default the [`cloudflared` Docker container](https://github.com/cloudflare/cloudflared/blob/master/Dockerfile#L29C6-L29C13) executes as a user called `nonroot` inside of the container. `nonroot` is a specific user that exists in the [base image](https://github.com/GoogleContainerTools/distroless/blob/859eeea1f9b3b7d59bdcd7e24a977f721e4a406c/base/base.bzl#L8) we use, and its Group ID is hardcoded to 65532. - - +5. (Recommended) To proxy traffic for diagnostic tools such as `ping` and `traceroute`, select **ICMP**. You may also need to [update your system](/cloudflare-one/connections/connect-networks/troubleshoot-tunnels/common-errors/#ping-and-traceroute-commands-do-not-work) to allow ICMP traffic through `cloudflared`. Cloudflare will now proxy traffic from enrolled devices, except for the traffic excluded in your [split tunnel settings](/cloudflare-one/connections/connect-networks/private-net/cloudflared/#3-route-private-network-ips-through-warp). For more information on how Gateway forwards traffic, refer to [Gateway proxy](/cloudflare-one/policies/gateway/proxy/).