diff --git a/public/__redirects b/public/__redirects index 40e468b0f72a75c..af73ebf83287866 100644 --- a/public/__redirects +++ b/public/__redirects @@ -716,7 +716,10 @@ /learning-paths/cybersafe/concepts/what-is-area1/ /learning-paths/cybersafe/concepts/what-is-email-security/ 301 /learning-paths/cybersafe/area1-onboarding/ /learning-paths/cybersafe/email-security-onboarding/ 301 - +## zero-trust-web access / clientless-access +/learning-paths/zero-trust-web-access/concepts/reverse-proxy-server/ https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/ 301 +/zero-trust-web-access/concepts/zero-trust/ https://www.cloudflare.com/learning/security/glossary/what-is-zero-trust/ 301 +/learning-paths/zero-trust-web-access/concepts/zero-trust-web-access/ /learning-paths/clientless-access/concepts/what-is-clientless-access/ 301 ## dns-filtering / secure-internet-traffic /learning-paths/dns-filtering/ /learning-paths/secure-internet-traffic/ 301 @@ -743,7 +746,7 @@ /learning-paths/secure-internet-traffic/ /learning-paths/secure-internet-traffic/concepts/ 301 /learning-paths/secure-o365-email/ /learning-paths/secure-o365-email/concepts/ 301 /learning-paths/workers/ /learning-paths/workers/concepts/ 301 -/learning-paths/zero-trust-web-access/ /learning-paths/zero-trust-web-access/concepts/ 301 +/learning-paths/clientless-access/ /learning-paths/clientless-access/concepts/ 301 /learning-paths/application-security/default-traffic-security/security-level/ /learning-paths/application-security/default-traffic-security/browser-integrity/ 301 # more redirects in the /dynamic/ section @@ -1899,6 +1902,8 @@ /learning-paths/dns-filtering/create-policy/* /learning-paths/secure-internet-traffic/build-dns-policies/:splat 301 ## Secure your Internet Traffic /learning-paths/secure-internet-traffic/connect-devices/* /learning-paths/secure-internet-traffic/connect-devices-networks/:splat 301 +## Zero Trust Web Access --> Clientless Access +/learning-paths/zero-trust-web-access/* /learning-paths/clientless-access/:splat 301 # Cloudflare for SaaS /ssl/ssl-for-saas/common-tasks/* /cloudflare-for-platforms/cloudflare-for-saas/ 301 diff --git a/src/content/docs/cloudflare-one/implementation-guides/clientless-access.mdx b/src/content/docs/cloudflare-one/implementation-guides/clientless-access.mdx new file mode 100644 index 000000000000000..836c1854f1a6d38 --- /dev/null +++ b/src/content/docs/cloudflare-one/implementation-guides/clientless-access.mdx @@ -0,0 +1,7 @@ +--- +pcx_content_type: navigation +title: Deploy clientless access +external_link: /learning-paths/clientless-access/concepts/ +sidebar: + order: 3 +--- diff --git a/src/content/docs/cloudflare-one/implementation-guides/index.mdx b/src/content/docs/cloudflare-one/implementation-guides/index.mdx index ecc057e8bbe6ffe..0b84084b5778af4 100644 --- a/src/content/docs/cloudflare-one/implementation-guides/index.mdx +++ b/src/content/docs/cloudflare-one/implementation-guides/index.mdx @@ -31,8 +31,8 @@ Implementation guides cover deployment steps and best practices for specific Clo Secure access to internal web applications without a device client. diff --git a/src/content/docs/cloudflare-one/implementation-guides/zero-trust-web-access.mdx b/src/content/docs/cloudflare-one/implementation-guides/zero-trust-web-access.mdx deleted file mode 100644 index c21f84f1b59dde6..000000000000000 --- a/src/content/docs/cloudflare-one/implementation-guides/zero-trust-web-access.mdx +++ /dev/null @@ -1,7 +0,0 @@ ---- -pcx_content_type: navigation -title: Deploy Zero Trust Web Access -external_link: /learning-paths/zero-trust-web-access/concepts/ -sidebar: - order: 3 ---- diff --git a/src/content/docs/learning-paths/zero-trust-web-access/access-application/best-practices.mdx b/src/content/docs/learning-paths/clientless-access/access-application/best-practices.mdx similarity index 83% rename from src/content/docs/learning-paths/zero-trust-web-access/access-application/best-practices.mdx rename to src/content/docs/learning-paths/clientless-access/access-application/best-practices.mdx index 7ee2917be77e92e..d42c5bb6757943d 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/access-application/best-practices.mdx +++ b/src/content/docs/learning-paths/clientless-access/access-application/best-practices.mdx @@ -20,6 +20,6 @@ Access applications have an inherently flexible and powerful domain structure ca ### Multiple domains in an application -Many customers who have workflows designed around internal web applications, especially those that were built internally, often see challenges related to interdependencies on multiple internal services. Separately, there can be challenges related to SPAs (Single-Page Applications) that make onboarding to a Zero Trust Web Access service difficult. For example, an application may have iFrames or other embedded systems that rely on different internal and/or external addresses. +Many customers who have workflows designed around internal web applications, especially those that were built internally, often see challenges related to interdependencies on multiple internal services. Separately, there can be challenges related to SPAs (Single-Page Applications) that make deploying clientless access difficult. For example, an application may have iFrames or other embedded systems that rely on different internal and/or external addresses. -If your internal service operates in this way, we recommend specifying multiple top-level domains in a single Access application. Otherwise, if the goal of using multiple domains is to streamline or simplify policy creation, we recommend making one primary domain per application, and automating the rest of your deployment [using Terraform](/learning-paths/zero-trust-web-access/terraform/) or another Infrastructure as Code (IaC) service. +If your internal service operates in this way, we recommend specifying multiple top-level domains in a single Access application. Otherwise, if the goal of using multiple domains is to streamline or simplify policy creation, we recommend making one primary domain per application, and automating the rest of your deployment [using Terraform](/learning-paths/clientless-access/terraform/) or another Infrastructure as Code (IaC) service. diff --git a/src/content/docs/learning-paths/zero-trust-web-access/access-application/create-access-app.mdx b/src/content/docs/learning-paths/clientless-access/access-application/create-access-app.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/access-application/create-access-app.mdx rename to src/content/docs/learning-paths/clientless-access/access-application/create-access-app.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/access-application/index.mdx b/src/content/docs/learning-paths/clientless-access/access-application/index.mdx similarity index 74% rename from src/content/docs/learning-paths/zero-trust-web-access/access-application/index.mdx rename to src/content/docs/learning-paths/clientless-access/access-application/index.mdx index 2030f09a16b98e5..bf42c8ee7e4a0ae 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/access-application/index.mdx +++ b/src/content/docs/learning-paths/clientless-access/access-application/index.mdx @@ -6,7 +6,7 @@ sidebar: --- -Now that you have [connected your private applications](/learning-paths/zero-trust-web-access/connect-private-applications/) to Cloudflare, secure those applications behind Cloudflare Access. +Now that you have [connected your private applications](/learning-paths/clientless-access/connect-private-applications/) to Cloudflare, secure those applications behind Cloudflare Access. ## Objectives diff --git a/src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/external-evaluation.mdx b/src/content/docs/learning-paths/clientless-access/advanced-workflows/external-evaluation.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/external-evaluation.mdx rename to src/content/docs/learning-paths/clientless-access/advanced-workflows/external-evaluation.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/index.mdx b/src/content/docs/learning-paths/clientless-access/advanced-workflows/index.mdx similarity index 94% rename from src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/index.mdx rename to src/content/docs/learning-paths/clientless-access/advanced-workflows/index.mdx index 7a4779c6593aa2e..a6e102840966a80 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/index.mdx +++ b/src/content/docs/learning-paths/clientless-access/advanced-workflows/index.mdx @@ -1,5 +1,5 @@ --- -title: Advanced ZTWA workflows +title: Advanced workflows pcx_content_type: overview sidebar: order: 7 diff --git a/src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/isolate-application.mdx b/src/content/docs/learning-paths/clientless-access/advanced-workflows/isolate-application.mdx similarity index 98% rename from src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/isolate-application.mdx rename to src/content/docs/learning-paths/clientless-access/advanced-workflows/isolate-application.mdx index c2e871a42912de3..6d28e9abe695118 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/isolate-application.mdx +++ b/src/content/docs/learning-paths/clientless-access/advanced-workflows/isolate-application.mdx @@ -230,7 +230,7 @@ Requires Data Loss Prevention add-on. Block users on unmanaged devices from downloading files that contain credit card numbers. This logic requires two policies: -- **Policy 1: [Disable file downloads in isolated browser](/learning-paths/zero-trust-web-access/advanced-workflows/isolate-application/#disable-file-downloads-in-isolated-browser)** +- **Policy 1: [Disable file downloads in isolated browser](/learning-paths/clientless-access/advanced-workflows/isolate-application/#disable-file-downloads-in-isolated-browser)** - **Policy 2: Block credit card numbers** diff --git a/src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/clientless-rbi.mdx b/src/content/docs/learning-paths/clientless-access/alternative-onramps/clientless-rbi.mdx similarity index 75% rename from src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/clientless-rbi.mdx rename to src/content/docs/learning-paths/clientless-access/alternative-onramps/clientless-rbi.mdx index 5f5ecf996602547..d1965e7d5fd9290 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/clientless-rbi.mdx +++ b/src/content/docs/learning-paths/clientless-access/alternative-onramps/clientless-rbi.mdx @@ -19,10 +19,10 @@ After the user authenticates to your IdP, Cloudflare will load the application i ## Setup -To configure Clientless Web Isolation for Zero Trust Web Access, refer to [this tutorial](/cloudflare-one/tutorials/clientless-access-private-dns/). +To configure Clientless Web Isolation to augment clientless access, refer to [this tutorial](/cloudflare-one/tutorials/clientless-access-private-dns/). ## Best practices * For guidance on building Gateway policies for private network applications, refer to [Secure your first application](/learning-paths/replace-vpn/build-policies/create-policy/). * If you already deployed the WARP client to some devices as part of a mixed-access methodology, ensure that your Gateway firewall policies do not rely on device posture checks. Because Clientless Web Isolation is not a machine in your fleet, it will not return any values for device posture checks. -* You can standardize the user experience by making specific applications available in your App Launcher as [bookmarks](/learning-paths/zero-trust-web-access/customize-ux/bookmarks/). In this case, you would create a new bookmark for `https://.cloudflareaccess.com/browser/https://internalresource.com`, which would take users directly to an isolated session with your application. +* You can standardize the user experience by making specific applications available in your App Launcher as [bookmarks](/learning-paths/clientless-access/customize-ux/bookmarks/). In this case, you would create a new bookmark for `https://.cloudflareaccess.com/browser/https://internalresource.com`, which would take users directly to an isolated session with your application. diff --git a/src/content/docs/learning-paths/clientless-access/alternative-onramps/index.mdx b/src/content/docs/learning-paths/clientless-access/alternative-onramps/index.mdx new file mode 100644 index 000000000000000..a059f15734c6db9 --- /dev/null +++ b/src/content/docs/learning-paths/clientless-access/alternative-onramps/index.mdx @@ -0,0 +1,15 @@ +--- +title: Alternative on-ramps +pcx_content_type: overview +sidebar: + order: 8 + +--- + +As discussed in the previous modules, almost everything you do with the Cloudflare reverse proxy requires [adding a site](/learning-paths/clientless-access/initial-setup/add-site/) to Cloudflare. That public DNS record (or its subdomains) becomes the domain on which your users access your private applications. This method is exceptionally secure and transparent; each domain and subdomain has access to the Cloudflare web security portfolio, are inherently DDoS protected, and receive an obfuscated origin IP. For these reasons, [public hostname routing](/learning-paths/clientless-access/connect-private-applications/) is the recommended method to onboard applications for clientless user access. However, there may be times in which a public DNS record cannot be created, or other situations that prevent administrators from using this method. + +## Objectives + +By the end of this module, you will be able to: + +* Connect to private web applications using their private hostnames. diff --git a/src/content/docs/learning-paths/clientless-access/concepts/index.mdx b/src/content/docs/learning-paths/clientless-access/concepts/index.mdx new file mode 100644 index 000000000000000..4c0a9c47e19294f --- /dev/null +++ b/src/content/docs/learning-paths/clientless-access/concepts/index.mdx @@ -0,0 +1,15 @@ +--- +title: Concepts +pcx_content_type: overview +sidebar: + order: 1 + +--- + +Review the concepts behind clientless access. + +## Objectives + +By the end of this module, you will be able to: + +- Understand the purpose and benefits of clientless access. \ No newline at end of file diff --git a/src/content/docs/learning-paths/clientless-access/concepts/what-is-clientless-access.mdx b/src/content/docs/learning-paths/clientless-access/concepts/what-is-clientless-access.mdx new file mode 100644 index 000000000000000..752e1972a1c39be --- /dev/null +++ b/src/content/docs/learning-paths/clientless-access/concepts/what-is-clientless-access.mdx @@ -0,0 +1,33 @@ +--- +title: What is clientless access? +pcx_content_type: overview +sidebar: + order: 1 + +--- + +Clientless access is a deployment option of a [Zero Trust Network Access (ZTNA)](https://www.cloudflare.com/learning/access-management/what-is-ztna/) service that provides secure access to internal applications without requiring end users to install any software. Users access corporate resources like intranet web apps, SSH terminals, and Windows servers through RDP from their web browser. Clientless access is commonly used to provide internal, [least-privilege access](https://www.cloudflare.com/learning/access-management/principle-of-least-privilege/) to users on unmanaged devices. Users may include third-party contractors, suppliers, and partners, or employees using personal mobile phones as part of an organization's bring-your-own-device (BYOD) policy. + +IT/security admins can decide how users authenticate, whether through their corporate identity provider, social media accounts, a PIN sent to their email, strong MFA, or a combination of options. Admins can also add inline services like Remote Browser Isolation (RBI) and Data Loss Prevention (DLP) to help prevent data exfiltration from unmanaged devices, still through a clientless implementation. Isolated apps can enforce broad data controls through the browser, such as preventing uploads/downloads or copy/paste, or incorporating DLP policies. + +## Alternatives to clientless access + +### Device client + +A device client enables additional capabilities for a ZTNA deployment, like adding full device posture checks to policy evaluations or providing access to private network resources on private hostnames. However, when extending access to third-party or temporary workers, some organizations are reluctant to buy and ship company-managed devices or onboard clients to users' personal devices. Some IT or security teams may have rigorous device compatibility, interoperability, or other software audit processes that could delay user onboarding for a ZTNA rollout. Contractors may also not allow external company software to be installed on their personal devices, whether a legacy VPN or a more modern software client. + +### Identity provider workarounds + +Some organizations historically have created corporate identities for third-party users within their internal identity provider, or they have spent the time to integrate a third-party's external identity provider with their own. Time and complexity for this work aside, not all resources integrate directly with traditional identity and access management (IAM) products, so a tool like ZTNA can still be needed to aggregate access logistics more broadly across an organization's internal resources. + +### Enterprise browsers + +Enterprise browsers are another tool sparking interest in the industry for hybrid work and internal access use cases. They aim to consolidate security features and provide similar unified access and data protection to resources, all through a managed browser. However, some users may not want to disrupt their preferred workflows through their existing browser(s), and some third parties may still not wish to install any external software including the managed browser. + +## Why Cloudflare for clientless access + +One of the biggest challenges in delivering clientless, secure remote access is making it feel native for your end users. Solutions have existed for decades which operate in a way that breaks TLS on a firewall or creates a picture-in-a-picture to access an internal web service. These legacy solutions make it very difficult to apply traditional web security concepts to private apps. + +In contrast, Cloudflare is a leading [reverse proxy](https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/) provider for public-facing web assets, proxying approximately [20% of all websites](https://w3techs.com/technologies/overview/proxy). Together with our [SASE platform](/reference-architecture/architectures/sase/), this establishes a unique position for Cloudflare to deliver performant browser-based security for both public and private resources. There is no additional overhead in implementation, management, ongoing updates, or routing. + +Clientless access accelerates user onboarding for your admins, and it makes private apps feel just like SaaS apps for your end users. Many organizations roll out clientless access use cases toward the start of their larger SASE architecture journey as a “quick win” to develop momentum for a longer [VPN replacement](/learning-paths/replace-vpn/concepts/) project or security modernization initiative. diff --git a/src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/best-practices.mdx b/src/content/docs/learning-paths/clientless-access/connect-private-applications/best-practices.mdx similarity index 98% rename from src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/best-practices.mdx rename to src/content/docs/learning-paths/clientless-access/connect-private-applications/best-practices.mdx index 7360867fa01f7b4..5ec8285b20a52f9 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/best-practices.mdx +++ b/src/content/docs/learning-paths/clientless-access/connect-private-applications/best-practices.mdx @@ -6,7 +6,7 @@ sidebar: --- -We recommend following these best practices when you deploy Cloudflare Tunnel for Zero Trust Web Access. +We recommend following these best practices when you deploy Cloudflare Tunnel for clientless access. ## Deploy another instance of cloudflared diff --git a/src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/create-tunnel.mdx b/src/content/docs/learning-paths/clientless-access/connect-private-applications/create-tunnel.mdx similarity index 94% rename from src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/create-tunnel.mdx rename to src/content/docs/learning-paths/clientless-access/connect-private-applications/create-tunnel.mdx index bc4ac1cf78388dc..7fe37db7dd75a42 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/create-tunnel.mdx +++ b/src/content/docs/learning-paths/clientless-access/connect-private-applications/create-tunnel.mdx @@ -24,7 +24,7 @@ To add a public hostname route to the tunnel: -All users on the Internet can now connect to this application via its public hostname. In [Module 4: Secure your applications](/learning-paths/zero-trust-web-access/access-application/), we will discuss how to restrict access to authorized users. +All users on the Internet can now connect to this application via its public hostname. In [Module 4: Secure your applications](/learning-paths/clientless-access/access-application/), we will discuss how to restrict access to authorized users. :::note diff --git a/src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/index.mdx b/src/content/docs/learning-paths/clientless-access/connect-private-applications/index.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/index.mdx rename to src/content/docs/learning-paths/clientless-access/connect-private-applications/index.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/customize-ux/app-launcher.mdx b/src/content/docs/learning-paths/clientless-access/customize-ux/app-launcher.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/customize-ux/app-launcher.mdx rename to src/content/docs/learning-paths/clientless-access/customize-ux/app-launcher.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/customize-ux/block-page.mdx b/src/content/docs/learning-paths/clientless-access/customize-ux/block-page.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/customize-ux/block-page.mdx rename to src/content/docs/learning-paths/clientless-access/customize-ux/block-page.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/customize-ux/bookmarks.mdx b/src/content/docs/learning-paths/clientless-access/customize-ux/bookmarks.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/customize-ux/bookmarks.mdx rename to src/content/docs/learning-paths/clientless-access/customize-ux/bookmarks.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/customize-ux/index.mdx b/src/content/docs/learning-paths/clientless-access/customize-ux/index.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/customize-ux/index.mdx rename to src/content/docs/learning-paths/clientless-access/customize-ux/index.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/customize-ux/login-page.mdx b/src/content/docs/learning-paths/clientless-access/customize-ux/login-page.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/customize-ux/login-page.mdx rename to src/content/docs/learning-paths/clientless-access/customize-ux/login-page.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/customize-ux/tags.mdx b/src/content/docs/learning-paths/clientless-access/customize-ux/tags.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/customize-ux/tags.mdx rename to src/content/docs/learning-paths/clientless-access/customize-ux/tags.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/add-site.mdx b/src/content/docs/learning-paths/clientless-access/initial-setup/add-site.mdx similarity index 76% rename from src/content/docs/learning-paths/zero-trust-web-access/initial-setup/add-site.mdx rename to src/content/docs/learning-paths/clientless-access/initial-setup/add-site.mdx index 27f09e4c93aa16e..5c5cdbe27a65adc 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/add-site.mdx +++ b/src/content/docs/learning-paths/clientless-access/initial-setup/add-site.mdx @@ -8,7 +8,7 @@ sidebar: import { Render } from "~/components" -In clientless ZTWA deployments, users connect to internal applications via public hostnames. You will need to own a domain, add it to Cloudflare, and configure Cloudflare as the [authoritative DNS provider](/dns/zone-setups/full-setup/setup/#update-your-nameservers) for that domain. Enterprise customers who cannot change their authoritative DNS provider have the option to configure a [partial (`CNAME`) setup](/dns/zone-setups/partial-setup/). +In clientless access deployments, users connect to internal applications via public hostnames. You will need to own a domain, add it to Cloudflare, and configure Cloudflare as the [authoritative DNS provider](/dns/zone-setups/full-setup/setup/#update-your-nameservers) for that domain. Enterprise customers who cannot change their authoritative DNS provider have the option to configure a [partial (`CNAME`) setup](/dns/zone-setups/partial-setup/). You only need to add one domain to Cloudflare, since you can create an infinite number of subdomains to manage all of your private applications. @@ -31,4 +31,4 @@ You only need to add one domain to Cloudflare, since you can create an infinite 6. 7. (Optional) Follow the **Quick Start Guide** to configure security and performance settings. -Registrars can take up to 24 hours to process nameserver changes. Your domain must be in an **Active** status before you can use it for Zero Trust Web Access. +Registrars can take up to 24 hours to process nameserver changes. Your domain must be in an **Active** status before you can use it for clientless access. diff --git a/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/configure-idp.mdx b/src/content/docs/learning-paths/clientless-access/initial-setup/configure-idp.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/initial-setup/configure-idp.mdx rename to src/content/docs/learning-paths/clientless-access/initial-setup/configure-idp.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/create-cloudflare-account.mdx b/src/content/docs/learning-paths/clientless-access/initial-setup/create-cloudflare-account.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/initial-setup/create-cloudflare-account.mdx rename to src/content/docs/learning-paths/clientless-access/initial-setup/create-cloudflare-account.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/create-zero-trust-org.mdx b/src/content/docs/learning-paths/clientless-access/initial-setup/create-zero-trust-org.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/initial-setup/create-zero-trust-org.mdx rename to src/content/docs/learning-paths/clientless-access/initial-setup/create-zero-trust-org.mdx diff --git a/src/content/docs/learning-paths/clientless-access/initial-setup/index.mdx b/src/content/docs/learning-paths/clientless-access/initial-setup/index.mdx new file mode 100644 index 000000000000000..07cad94d013f190 --- /dev/null +++ b/src/content/docs/learning-paths/clientless-access/initial-setup/index.mdx @@ -0,0 +1,20 @@ +--- +title: Initial setup +pcx_content_type: overview +sidebar: + order: 2 + +--- + +In this guide, you will learn how to deliver clientless access using the Cloudflare Zero Trust suite of products. This guide will focus on browser-based applications that do not require users to install a device client of any kind. It will discuss both common and complex scenarios, and should give you the tools to provide secure user access to internal web applications following a [Zero Trust model](https://www.cloudflare.com/learning/security/glossary/what-is-zero-trust/). + +If you need to deliver access to non-browser based applications, refer to our complementary guide for [replacing your VPN](/learning-paths/clientless-access/concepts/). + +## Objectives + +By the end of this module, you will be able to: + +* Set up a Cloudflare account. +* Add your domain to Cloudflare. +* Create a Zero Trust organization to manage applications and policies. +* Configure an identity provider (IdP) for user authentication. diff --git a/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/best-practices.mdx b/src/content/docs/learning-paths/clientless-access/migrate-applications/best-practices.mdx similarity index 61% rename from src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/best-practices.mdx rename to src/content/docs/learning-paths/clientless-access/migrate-applications/best-practices.mdx index e0dbf0eeca2b52d..fd635d3c388cc99 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/best-practices.mdx +++ b/src/content/docs/learning-paths/clientless-access/migrate-applications/best-practices.mdx @@ -6,12 +6,12 @@ sidebar: --- -Most customers have a heterogeneous private application portfolio; some are home-built, some are internal managed services, some have SSO integrations available, and some rely on HTML or other forms of authentication. With that in mind, we recommend that you mix-and-match [onboarding solutions](/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso/#potential-solutions) to fit the needs of each individual application. As shown in the table below, you can bucket applications into a series of stack-ranked categories that prioritize ease of implementation and total organizational impact. +Most customers have a heterogeneous private application portfolio; some are home-built, some are internal managed services, some have SSO integrations available, and some rely on HTML or other forms of authentication. With that in mind, we recommend that you mix-and-match [onboarding solutions](/learning-paths/clientless-access/migrate-applications/integrated-sso/#potential-solutions) to fit the needs of each individual application. As shown in the table below, you can bucket applications into a series of stack-ranked categories that prioritize ease of implementation and total organizational impact. | Application type | Recommendation | Outcome | | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Private web apps without integrated SSO | [Present applications exclusively on Cloudflare domains.](/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso/#recommended-solution) | Users access applications on new domains delegated to Cloudflare and instantly apply SSO through Cloudflare integration. | -| Private web apps with integrated SSO | **If SSO configuration is possible:** [Present applications exclusively on Cloudflare domains.](/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso/#recommended-solution)
**If SSO configuration is not possible:** Present applications on existing internal domains with identical external domains delegated to Cloudflare | Users access internal web services on the same or new domains from Cloudflare. If configured, the SSO provider transparently redirects users from internal domains to Cloudflare authoritative external domains. | -| New critical internal applications being developed | [Present applications exclusively on Cloudflare domains.](/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso/#recommended-solution) | Developers can programmatically generate (or be given) new public hostnames on Cloudflare to represent the redirects for their application in SAML or OIDC integrations. | -| New microservices being developed | [Present applications exclusively on Cloudflare domains.](/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso/#recommended-solution)
Optionally, [consume the Access JWT](/learning-paths/zero-trust-web-access/migrate-applications/consume-jwt/#consume-the-cloudflare-jwt) as authentication in internal applications. | Developers can inject the JWT authorization mechanism directly into the codebase of their application and [use Terraform](/learning-paths/zero-trust-web-access/terraform/) to automatically build Cloudflare hostnames and policies for their applications. | +| Private web apps without integrated SSO | [Present applications exclusively on Cloudflare domains.](/learning-paths/clientless-access/migrate-applications/integrated-sso/#recommended-solution) | Users access applications on new domains delegated to Cloudflare and instantly apply SSO through Cloudflare integration. | +| Private web apps with integrated SSO | **If SSO configuration is possible:** [Present applications exclusively on Cloudflare domains.](/learning-paths/clientless-access/migrate-applications/integrated-sso/#recommended-solution)
**If SSO configuration is not possible:** Present applications on existing internal domains with identical external domains delegated to Cloudflare | Users access internal web services on the same or new domains from Cloudflare. If configured, the SSO provider transparently redirects users from internal domains to Cloudflare authoritative external domains. | +| New critical internal applications being developed | [Present applications exclusively on Cloudflare domains.](/learning-paths/clientless-access/migrate-applications/integrated-sso/#recommended-solution) | Developers can programmatically generate (or be given) new public hostnames on Cloudflare to represent the redirects for their application in SAML or OIDC integrations. | +| New microservices being developed | [Present applications exclusively on Cloudflare domains.](/learning-paths/clientless-access/migrate-applications/integrated-sso/#recommended-solution)
Optionally, [consume the Access JWT](/learning-paths/clientless-access/migrate-applications/consume-jwt/#consume-the-cloudflare-jwt) as authentication in internal applications. | Developers can inject the JWT authorization mechanism directly into the codebase of their application and [use Terraform](/learning-paths/clientless-access/terraform/) to automatically build Cloudflare hostnames and policies for their applications. | | Internal API endpoints (including internal applications with dependencies on external/internal APIs) | Present internal APIs on Cloudflare domains, and build Access policies that accept [service tokens](/cloudflare-one/identity/service-tokens/) alongside user-oriented policies. | Automated systems can authenticate via a [service token in the request header](/cloudflare-one/identity/service-tokens/#connect-your-service-to-access), while end users continue to login through their IdP. | diff --git a/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/consume-jwt.mdx b/src/content/docs/learning-paths/clientless-access/migrate-applications/consume-jwt.mdx similarity index 59% rename from src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/consume-jwt.mdx rename to src/content/docs/learning-paths/clientless-access/migrate-applications/consume-jwt.mdx index 8b0f515cb6090c6..2d72aa7a15649b5 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/consume-jwt.mdx +++ b/src/content/docs/learning-paths/clientless-access/migrate-applications/consume-jwt.mdx @@ -8,9 +8,9 @@ sidebar: A common goal for many security organizations is to implement continuous authentication and authorization. With Cloudflare Access JWT validation, you can achieve this goal without introducing significant user interruption or requiring behavioral changes for your end users. -As discussed on the [previous page](/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso/), some of your applications may currently rely on a direct SSO integration to authenticate requests. However, if you were to put this type of application behind Cloudflare to enable remote access, your user would need to authenticate twice. First, they must authenticate to your identity provider via Cloudflare Access. Once they have authenticated to Access, your user will reach the front door of your internal application, where they must complete a second authentication event via the direct SSO integration. +As discussed on the [previous page](/learning-paths/clientless-access/migrate-applications/integrated-sso/), some of your applications may currently rely on a direct SSO integration to authenticate requests. However, if you were to put this type of application behind Cloudflare to enable remote access, your user would need to authenticate twice. First, they must authenticate to your identity provider via Cloudflare Access. Once they have authenticated to Access, your user will reach the front door of your internal application, where they must complete a second authentication event via the direct SSO integration. -Instead of [managing a direct SSO integration](/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso/) in your application, we recommend using the JSON Web Token (JWT) issued by Cloudflare Access to authenticate requests. Cloudflare becomes the primary responsible party for validating the token returned from your SSO provider. By allowing your applications to consume the Cloudflare JWT, users will only have a single authentication event required to access the application, and you can better manage authorization to your internal services with lower overhead. +Instead of [managing a direct SSO integration](/learning-paths/clientless-access/migrate-applications/integrated-sso/) in your application, we recommend using the JSON Web Token (JWT) issued by Cloudflare Access to authenticate requests. Cloudflare becomes the primary responsible party for validating the token returned from your SSO provider. By allowing your applications to consume the Cloudflare JWT, users will only have a single authentication event required to access the application, and you can better manage authorization to your internal services with lower overhead. ## Consume the Cloudflare JWT diff --git a/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/index.mdx b/src/content/docs/learning-paths/clientless-access/migrate-applications/index.mdx similarity index 88% rename from src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/index.mdx rename to src/content/docs/learning-paths/clientless-access/migrate-applications/index.mdx index d9647efd66e9e47..f36d6ff63b75c76 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/index.mdx +++ b/src/content/docs/learning-paths/clientless-access/migrate-applications/index.mdx @@ -10,7 +10,7 @@ Publish internal applications that users currently access from a traditional cor :::note -The remaining modules (Modules 6-9) discuss special considerations and setup options for enterprise environments. If you are only looking to configure a basic ZTWA setup, feel free to skip them. +The remaining modules (Modules 6-9) discuss special considerations and setup options for enterprise environments. If you are only looking to configure a basic clientless access setup, feel free to skip them. ::: ## Objectives diff --git a/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso.mdx b/src/content/docs/learning-paths/clientless-access/migrate-applications/integrated-sso.mdx similarity index 88% rename from src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso.mdx rename to src/content/docs/learning-paths/clientless-access/migrate-applications/integrated-sso.mdx index 28735be02860a19..a31c7dddcad800f 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso.mdx +++ b/src/content/docs/learning-paths/clientless-access/migrate-applications/integrated-sso.mdx @@ -6,7 +6,7 @@ sidebar: --- -Many organizations in the past few years have recognized the importance of source-of-truth identity and have directly integrated their SSO provider with their internal applications. The SSO provider is only aware of the internal domain on which the application exists (via the configured ACS URL), which means the user must be connected to the local network in order to access the application. This security architecture makes sense for a traditional network perimeter, but it presents challenges for Zero Trust adoption. In the ZTWA model, the user's device has no concept of an internal corporate network, only the specific, scoped applications to which they have access. The problem is summarized in the following diagram: +Many organizations in the past few years have recognized the importance of source-of-truth identity and have directly integrated their SSO provider with their internal applications. The SSO provider is only aware of the internal domain on which the application exists (via the configured ACS URL), which means the user must be connected to the local network in order to access the application. This security architecture makes sense for a traditional network perimeter, but it presents challenges for Zero Trust adoption. In the clientless access model, the user's device has no concept of an internal corporate network, only the specific, scoped applications to which they have access. The problem is summarized in the following diagram: ```mermaid flowchart LR @@ -29,7 +29,7 @@ If your applications use integrated SSO, there are a number of different paths y | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | [Present applications exclusively on Cloudflare domains](#recommended-solution) | Change SSO ACS URL to the Cloudflare Tunnel public hostname |
  • Increased security posture
  • No changes to application code
  • No changes to internal DNS design
    • | Hard cutover event when ACS URL changes from internal to external domain | | Present applications on existing internal domains with identical external domains delegated to Cloudflare | Add domains to Cloudflare that match internal domains |
  • No changes to SSO ACS URL
  • No change for end users
    • |
  • Requires careful management of internal and external domains
  • Requires changing internal DNS design
    • | -| [Consume the Cloudflare JWT in internal applications](/learning-paths/zero-trust-web-access/migrate-applications/consume-jwt/) |
  • Remove integrated SSO
  • Update application to accept the Cloudflare JWT for user authorization
    • |
  • Reduced authentication burden for end users
  • No changes to internal DNS design
  • Instantly secure applications without direct SSO integration
    • |
  • Requires changing application code
  • Hard cutover event when application updates
    • | +| [Consume the Cloudflare JWT in internal applications](/learning-paths/clientless-access/migrate-applications/consume-jwt/) |
  • Remove integrated SSO
  • Update application to accept the Cloudflare JWT for user authorization
    • |
  • Reduced authentication burden for end users
  • No changes to internal DNS design
  • Instantly secure applications without direct SSO integration
    • |
  • Requires changing application code
  • Hard cutover event when application updates
    • | | Use Cloudflare as the direct SSO integration, which then calls your IdP of choice (Okta, OneLogin, etc.) | Swap existing SSO provider for [Access for SaaS](/cloudflare-one/applications/configure-apps/saas-apps/) |
  • Increased flexibility for changing IdPs
  • Ability to use multiple IdPs simultaneously
    • |
  • Hard cutover event for IdP changes
  • No SCIM provisioning for application
    • | ## Recommended solution diff --git a/src/content/docs/learning-paths/zero-trust-web-access/terraform/index.mdx b/src/content/docs/learning-paths/clientless-access/terraform/index.mdx similarity index 100% rename from src/content/docs/learning-paths/zero-trust-web-access/terraform/index.mdx rename to src/content/docs/learning-paths/clientless-access/terraform/index.mdx diff --git a/src/content/docs/learning-paths/zero-trust-web-access/terraform/publish-apps-with-terraform.mdx b/src/content/docs/learning-paths/clientless-access/terraform/publish-apps-with-terraform.mdx similarity index 93% rename from src/content/docs/learning-paths/zero-trust-web-access/terraform/publish-apps-with-terraform.mdx rename to src/content/docs/learning-paths/clientless-access/terraform/publish-apps-with-terraform.mdx index 41f15505f0a41fd..60d0bcf31f48457 100644 --- a/src/content/docs/learning-paths/zero-trust-web-access/terraform/publish-apps-with-terraform.mdx +++ b/src/content/docs/learning-paths/clientless-access/terraform/publish-apps-with-terraform.mdx @@ -11,9 +11,9 @@ This guide covers how to use the [Cloudflare Terraform provider](https://registr ## Prerequisites -- [Add your domain to Cloudflare](/learning-paths/zero-trust-web-access/initial-setup/add-site/) -- [Configure an IdP integration](/learning-paths/zero-trust-web-access/initial-setup/configure-idp/) -- [Create a Cloudflare Tunnel](/learning-paths/zero-trust-web-access/connect-private-applications/create-tunnel/#create-a-tunnel) via the Zero Trust dashboard +- [Add your domain to Cloudflare](/learning-paths/clientless-access/initial-setup/add-site/) +- [Configure an IdP integration](/learning-paths/clientless-access/initial-setup/configure-idp/) +- [Create a Cloudflare Tunnel](/learning-paths/clientless-access/connect-private-applications/create-tunnel/#create-a-tunnel) via the Zero Trust dashboard - Install the [Terraform client](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) - [Create an API token](/fundamentals/api/get-started/create-token/) (refer to the [minimum required permissions](/cloudflare-one/connections/connect-networks/deployment-guides/terraform/#3-create-a-cloudflare-api-token)) diff --git a/src/content/docs/learning-paths/replace-vpn/get-started/index.mdx b/src/content/docs/learning-paths/replace-vpn/get-started/index.mdx index ac9d54ee85ec5db..55226fecb838ce7 100644 --- a/src/content/docs/learning-paths/replace-vpn/get-started/index.mdx +++ b/src/content/docs/learning-paths/replace-vpn/get-started/index.mdx @@ -16,7 +16,7 @@ This guide will highlight best practices to follow and other decisions to consid :::note -This learning path focuses on client-based remote access to internal services. If you are looking for clientless or Zero Trust Web Access functionality, refer to our [Deploy Zero Trust Web Access](/learning-paths/zero-trust-web-access/concepts/) learning path. +This learning path focuses on client-based remote access to internal services. If you are looking for clientless or browser-based functionality, refer to our [Deploy clientless access](/learning-paths/clientless-access/concepts/) learning path. ::: ## Objectives diff --git a/src/content/docs/learning-paths/secure-internet-traffic/build-http-policies/browser-isolation.mdx b/src/content/docs/learning-paths/secure-internet-traffic/build-http-policies/browser-isolation.mdx index 0c97a3f510fa197..e556bab2b3fd6e2 100644 --- a/src/content/docs/learning-paths/secure-internet-traffic/build-http-policies/browser-isolation.mdx +++ b/src/content/docs/learning-paths/secure-internet-traffic/build-http-policies/browser-isolation.mdx @@ -9,7 +9,7 @@ import { GlossaryDefinition, TabItem, Tabs } from "~/components"; -Browser Isolation provides unique and transparent protection for your users using methods that surpass the capabilities of a traditional secure web gateway. This section focuses primarily on Browser Isolation for external services, assuming that most traffic from a device or a network is being forwarded to Cloudflare. For other applications of Browser Isolation, refer to the [Zero Trust Web Access (ZTWA) learning path](/learning-paths/zero-trust-web-access/concepts/). +Browser Isolation provides unique and transparent protection for your users using methods that surpass the capabilities of a traditional secure web gateway. This section focuses primarily on Browser Isolation for external services, assuming that most traffic from a device or a network is being forwarded to Cloudflare. For other applications of Browser Isolation, refer to the [Deploy clientless access](/learning-paths/clientless-access/concepts/) guide. As a note, Cloudflare's Browser Isolation technology was built to be used for 100% of your user's daily browsing. These recommendations do not suggest that you should limit or be cautious with your use of Browser Isolation, but instead help identify practical outcomes that balance technology with actualized security benefits. diff --git a/src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/index.mdx b/src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/index.mdx deleted file mode 100644 index 0ec23adebb94cf3..000000000000000 --- a/src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/index.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Alternative ZTWA on-ramps -pcx_content_type: overview -sidebar: - order: 8 - ---- - -As discussed in the previous modules, almost everything you do with the Cloudflare reverse proxy requires [adding a site](/learning-paths/zero-trust-web-access/initial-setup/add-site/) to Cloudflare. That public DNS record (or its subdomains) becomes the domain on which your users access your private applications. This method is exceptionally secure and transparent; each domain and subdomain has access to the Cloudflare web security portfolio, are inherently DDoS protected, and receive an obfuscated origin IP. For these reasons, [public hostname routing](/learning-paths/zero-trust-web-access/connect-private-applications/) is the recommended method to onboard applications for clientless user access. However, there may be times in which a public DNS record cannot be created, or other situations that prevent administrators from using this method. - -## Objectives - -By the end of this module, you will be able to: - -* Connect to private web applications using their private hostnames. diff --git a/src/content/docs/learning-paths/zero-trust-web-access/concepts/index.mdx b/src/content/docs/learning-paths/zero-trust-web-access/concepts/index.mdx deleted file mode 100644 index 8defda00eab52a8..000000000000000 --- a/src/content/docs/learning-paths/zero-trust-web-access/concepts/index.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Concepts -pcx_content_type: overview -sidebar: - order: 1 - ---- - -Review the concepts behind Zero Trust Web Access. - -## Objectives - -By the end of this module, you will be able to: - -* Understand the purpose and benefits of a reverse proxy server. -* Describe the main principles of Zero Trust security. -* Understand how Zero Trust Web Access fits into a Zero Trust security model. diff --git a/src/content/docs/learning-paths/zero-trust-web-access/concepts/reverse-proxy-server.mdx b/src/content/docs/learning-paths/zero-trust-web-access/concepts/reverse-proxy-server.mdx deleted file mode 100644 index ad3151c9e18f35a..000000000000000 --- a/src/content/docs/learning-paths/zero-trust-web-access/concepts/reverse-proxy-server.mdx +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: What is a reverse proxy? -pcx_content_type: overview -sidebar: - order: 1 - ---- - -import { Render } from "~/components" - - - - diff --git a/src/content/docs/learning-paths/zero-trust-web-access/concepts/zero-trust-web-access.mdx b/src/content/docs/learning-paths/zero-trust-web-access/concepts/zero-trust-web-access.mdx deleted file mode 100644 index a418334f4df65da..000000000000000 --- a/src/content/docs/learning-paths/zero-trust-web-access/concepts/zero-trust-web-access.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: What is Zero Trust Web Access? -pcx_content_type: overview -sidebar: - order: 3 - ---- - -Zero Trust Web Access (ZTWA), also known as Zero Trust Application Access (ZTAA), provides users with secure access to internal applications using Zero Trust principles. ZTWA authenticates users to applications by integrating with [identity providers](https://www.cloudflare.com/learning/access-management/what-is-an-identity-provider/), encrypting connections, considering each access request for an application individually, and blocking or allowing on a request-by-request basis. - -## ZTNA vs. ZTWA - -Zero Trust Network Access (ZTNA) and Zero Trust Web Access (ZTWA) are complementary solutions for securely connecting users to internal resources. - -ZTNA focuses on granting access to private networks. ZTNA implementations usually involve installing device client software in order to access non-HTTP resources and filter network traffic. - -ZTWA, on the other hand, focuses on granting access to specific applications on the network. ZTWA can be delivered without a device client for HTTP resources that are accessed in a browser. Clientless deployments allow organizations to quickly onboard users to their applications, especially users on unmanaged devices such as third-party contractors or vendors. - -## Where Cloudflare differs in the ZTWA approach - -One of the biggest challenges in delivering clientless, secure remote access is making it feel native for your end users. Solutions have existed for decades which operate in a way that breaks TLS on a firewall or creates a picture-in-a-picture to access an internal web service. These legacy solutions make it very difficult to apply traditional web security concepts to private applications. - -In contrast, Cloudflare is the [leading reverse proxy provider](https://www.cloudflare.com/application-services/products/) for public-facing websites and applications, which gives us a unique capability to deliver seamless security and networking services for private applications. There is no additional overhead in implementation, management, ongoing updates, or routing; everything works for your administrators like a standard Cloudflare application. Most importantly, our ZTWA solution makes private applications feel like a SaaS applications for your end users, complete with security, performance, and consistency. diff --git a/src/content/docs/learning-paths/zero-trust-web-access/concepts/zero-trust.mdx b/src/content/docs/learning-paths/zero-trust-web-access/concepts/zero-trust.mdx deleted file mode 100644 index 1abae2baf3893b3..000000000000000 --- a/src/content/docs/learning-paths/zero-trust-web-access/concepts/zero-trust.mdx +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: What is Zero Trust? -pcx_content_type: overview -sidebar: - order: 2 - ---- - -Zero Trust is a security approach built on the assumption that threats are already present within an organization. In a Zero Trust approach, no user, device, or application is automatically trusted — instead, strict identity verification is applied to every request anywhere in a corporate network, even for users and devices already connected to that network. - -Zero Trust emphasizes the [principle of least privilege](https://www.cloudflare.com/learning/access-management/principle-of-least-privilege/) for access control, where users only have access to the applications they need to do their job. More importantly, once the user's identity is confirmed, Zero Trust still does not automatically trust that person's actions. Instead, Zero Trust enforces continuous verification of user and device identity: users are required to periodically reauthenticate, and every request is monitored and inspected individually for compromised activity. - -The primary benefit of a Zero Trust security model is to help reduce an organization's attack surface. Because Zero Trust only grants access to a specific application and denies access to all other resources by default, a compromised user account or device will only impact a small segment of the network. diff --git a/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/index.mdx b/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/index.mdx deleted file mode 100644 index 4c25709b9ffa0e9..000000000000000 --- a/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/index.mdx +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Initial setup -pcx_content_type: overview -sidebar: - order: 2 - ---- - -In this guide, you will learn how to deliver Zero Trust Web Access using the Cloudflare Zero Trust suite of products. This guide will focus on browser-based applications that do not require users to install a device client of any kind. It will discuss both common and complex scenarios, and should give you the tools to provide secure user access to internal web applications following a Zero Trust model. - -If you need to deliver access to non-browser based applications, refer to our complementary guide for [replacing your VPN](/learning-paths/zero-trust-web-access/concepts/). - -## Objectives - -By the end of this module, you will be able to: - -* Set up a Cloudflare account. -* Add your domain to Cloudflare. -* Create a Zero Trust organization to manage applications and policies. -* Configure an identity provider (IdP) for user authentication. diff --git a/src/content/docs/reference-architecture/by-solution.mdx b/src/content/docs/reference-architecture/by-solution.mdx index e0b769e57fce68b..89ac74ca93f4c2a 100644 --- a/src/content/docs/reference-architecture/by-solution.mdx +++ b/src/content/docs/reference-architecture/by-solution.mdx @@ -59,7 +59,7 @@ Architecture documentation related to using Cloudflare for Zero Trust, SSE and S - [Secure your Internet traffic and SaaS apps](/learning-paths/secure-internet-traffic/concepts/) - [Replace your VPN](/learning-paths/replace-vpn/concepts/) -- [Deploy Zero Trust Web Access](/learning-paths/zero-trust-web-access/concepts/) +- [Deploy clientless access](/learning-paths/clientless-access/concepts/) - [Secure Microsoft 365 email with Email Security](/learning-paths/secure-o365-email/concepts/) ### Networking 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 25875dbb317892e..266cf298e654063 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 @@ -512,4 +512,4 @@ Related resources - [Cloudflare SASE reference architecture](/reference-architecture/architectures/sase/) - [Using Cloudflare SASE with Microsoft](/reference-architecture/architectures/cloudflare-sase-with-microsoft/) -- [How to deploy Cloudflare ZTNA](/learning-paths/zero-trust-web-access/concepts/) +- [How to deploy Cloudflare ZTNA](/learning-paths/clientless-access/concepts/) diff --git a/src/content/docs/reference-architecture/design-guides/zero-trust-for-saas.mdx b/src/content/docs/reference-architecture/design-guides/zero-trust-for-saas.mdx index 6567a1e117dc6db..05264afe4066f64 100644 --- a/src/content/docs/reference-architecture/design-guides/zero-trust-for-saas.mdx +++ b/src/content/docs/reference-architecture/design-guides/zero-trust-for-saas.mdx @@ -86,7 +86,7 @@ Organizations that already use IP allow lists to secure access to SaaS applicati - **Hybrid employees:** Connecting to Cloudflare using our Zero Trust client, [WARP](/cloudflare-one/connections/connect-devices/warp/). - **Office-based users:** Connecting to a local network which routes Internet bound traffic to Cloudflare through GRE or IPsec [Magic WAN tunnels](/magic-wan/). -- **Contractors and external users:** Accessing SaaS applications through a [remote browser](/learning-paths/zero-trust-web-access/alternative-onramps/clientless-rbi/) hosted in a Cloudflare data center. +- **Contractors and external users:** Accessing SaaS applications through a [remote browser](/learning-paths/clientless-access/alternative-onramps/clientless-rbi/) hosted in a Cloudflare data center. Organizations add the new dedicated egress IPs to the existing SaaS IP allow lists for the Cloudflare sourced traffic to be allowed into the SaaS application. This way, organizations can maintain legacy connectivity methods in parallel with Cloudflare and migrate users gradually. Once all users are migrated to access with Cloudflare, the SaaS IP allow lists can be updated by removing the IPs corresponding to legacy infrastructure. diff --git a/src/content/docs/reference-architecture/implementation-guides/index.mdx b/src/content/docs/reference-architecture/implementation-guides/index.mdx index 4f7380fdf219c96..e5bcda9c736449d 100644 --- a/src/content/docs/reference-architecture/implementation-guides/index.mdx +++ b/src/content/docs/reference-architecture/implementation-guides/index.mdx @@ -15,7 +15,7 @@ Implementation guides provide [step-by-step instructions](/reference-architectur - [Secure your Internet traffic and SaaS apps](/learning-paths/secure-internet-traffic/concepts/) - [Replace your VPN](/learning-paths/replace-vpn/concepts/) -- [Deploy Zero Trust Web Access](/learning-paths/zero-trust-web-access/concepts/) +- [Deploy Zero Trust Web Access](/learning-paths/clientless-access/concepts/) - [Secure Microsoft 365 email with Email Security](/learning-paths/secure-o365-email/concepts/) ## Application Security diff --git a/src/content/docs/reference-architecture/implementation-guides/zero-trust/index.mdx b/src/content/docs/reference-architecture/implementation-guides/zero-trust/index.mdx index 8e7d67573d06511..518428dc317bc9f 100644 --- a/src/content/docs/reference-architecture/implementation-guides/zero-trust/index.mdx +++ b/src/content/docs/reference-architecture/implementation-guides/zero-trust/index.mdx @@ -14,5 +14,5 @@ Zero Trust implementation guides walk you through the steps to deploy a Zero Tru - [Secure your Internet traffic and SaaS apps](/learning-paths/secure-internet-traffic/concepts/) - [Replace your VPN](/learning-paths/replace-vpn/concepts/) -- [Deploy Zero Trust Web Access](/learning-paths/zero-trust-web-access/concepts/) +- [Deploy Zero Trust Web Access](/learning-paths/clientless-access/concepts/) - [Secure Microsoft 365 email with Email Security](/learning-paths/secure-o365-email/concepts/) diff --git a/src/content/docs/reference-architecture/implementation-guides/zero-trust/ztna-web-access.mdx b/src/content/docs/reference-architecture/implementation-guides/zero-trust/ztna-web-access.mdx index c21f84f1b59dde6..836c1854f1a6d38 100644 --- a/src/content/docs/reference-architecture/implementation-guides/zero-trust/ztna-web-access.mdx +++ b/src/content/docs/reference-architecture/implementation-guides/zero-trust/ztna-web-access.mdx @@ -1,7 +1,7 @@ --- pcx_content_type: navigation -title: Deploy Zero Trust Web Access -external_link: /learning-paths/zero-trust-web-access/concepts/ +title: Deploy clientless access +external_link: /learning-paths/clientless-access/concepts/ sidebar: order: 3 --- diff --git a/src/content/docs/ssl/post-quantum-cryptography/pqc-and-zero-trust.mdx b/src/content/docs/ssl/post-quantum-cryptography/pqc-and-zero-trust.mdx index 96c50bfb6683cf5..ca200e58fbcbe9b 100644 --- a/src/content/docs/ssl/post-quantum-cryptography/pqc-and-zero-trust.mdx +++ b/src/content/docs/ssl/post-quantum-cryptography/pqc-and-zero-trust.mdx @@ -12,7 +12,7 @@ Refer to the sections below to learn about the use cases supported by the Zero T ## Agentless Cloudflare Access -You can use [Cloudflare Access](/cloudflare-one/policies/access/) [self-hosted applications](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) in an agentless configuration to protect your organization's Internet traffic to internal web applications. Refer to the [learning path](/learning-paths/zero-trust-web-access/initial-setup/) for detailed guidance. +You can use [Cloudflare Access](/cloudflare-one/policies/access/) [self-hosted applications](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) in an agentless configuration to protect your organization's Internet traffic to internal web applications. Refer to the [learning path](/learning-paths/clientless-access/initial-setup/) for detailed guidance. Even if the applications themselves have not yet migrated to post-quantum (PQ) cryptography, they will be protected against quantum threats. diff --git a/src/content/learning-paths/zero-trust-web-access.json b/src/content/learning-paths/clientless-access.json similarity index 75% rename from src/content/learning-paths/zero-trust-web-access.json rename to src/content/learning-paths/clientless-access.json index d9f918fc29336c9..ea51e2ce9d60b1e 100644 --- a/src/content/learning-paths/zero-trust-web-access.json +++ b/src/content/learning-paths/clientless-access.json @@ -1,6 +1,6 @@ { - "title": "Deploy Zero Trust Web Access", - "path": "/learning-paths/zero-trust-web-access/concepts/", + "title": "Deploy clientless access", + "path": "/learning-paths/clientless-access/concepts/", "priority": 2, "description": "Secure access to internal web applications without a device client.", "products": [