Fixing table formatting

Author: securitypedant

src/content/docs/reference-architecture/design-guides/designing-ztna-access-policies.mdx

@@ -89,7 +89,9 @@ Cloudflare Access supports four main types of applications:
 - **SaaS** applications are accessed over the public Internet, and therefore do not require any tunnel connectivity to Cloudflare. Instead, Access acts as an identity proxy between users and the SaaS application. When a user attempts to access the SaaS app, they're first authenticated by Cloudflare, which redirects to your main identity service. SaaS applications are then configured via SAML or OAuth to trust Cloudflare. This allows organizations to implement additional security layers (like device posture checks) and centralize access control for their SaaS applications, even if the SaaS or identity provider doesn't natively support these features.
 - **Infrastructure** applications enable users to control access to individual servers, clusters or databases in a private network. Infrastructure apps work by defining a ‘target’ proxied over cloudflared, but allows users to group multiple machines under the same target \- essentially, allowing users to define common access policies across potentially disparate infrastructure resources. Built-in access and command logging capabilities means organizations can maintain detailed audit trails for compliance and security investigation purposes.
 
-  Note: It is possible to configure SaaS applications to accept traffic only coming from Cloudflare. This forces all SaaS application traffic to be proxied and routed via Cloudflare Gateway which, in turn, allows for the use of security controls to inspect and filter traffic such as downloads of sensitive company data from SaaS applications. The second use case below will describe how to achieve this.
+:::note[]
+It is possible to configure SaaS applications to accept traffic only coming from Cloudflare. This forces all SaaS application traffic to be proxied and routed via Cloudflare Gateway which, in turn, allows for the use of security controls to inspect and filter traffic such as downloads of sensitive company data from SaaS applications. The second use case below will describe how to achieve this.
+:::
 
 Access applications typically map directly to a single application. However, it is possible to have an Access application, and its associated policies sit in front of more than one application endpoint. This might be a range of IPs related to multiple Windows RDP servers where you wish to implement a common access policy. The same idea can also be applied to public hostnames, where you might have more than one hostname that refers to several applications you wish to have the same policies. For instance, you might have wiki.domain.com and wiki.domain.co.uk — different application instances, but with common access policy requirements.
 
@@ -130,7 +132,9 @@ The Action field in a policy determines what happens when a user or service matc
 - **Bypass** allows users or services to disable any enforcement for traffic before accessing the application. For example, a specific endpoint in an application may need to be broadly accessible over the Internet.
 - **Service Auth** allows you to authenticate requests from other services or applications using [mTLS](/ssl/client-certificates/enable-mtls/) or [service tokens](/cloudflare-one/identity/service-tokens/). No login page will be presented to the user or service if they meet this policy criteria. This is designed so non-user requests, i.e. other applications can access secured resources.
 
-Note: Cloudflare Access is a deny by default service, which means if a request does not match any policy action, the default action is “Block.”
+:::note[]
+Cloudflare Access is a deny by default service, which means if a request does not match any policy action, the default action is “Block.”
+:::
 
 #### Session duration
 
@@ -156,49 +160,52 @@ The above diagram visualises an example for the policy "All employees and contra
 
 There are many different [types of selectors](/cloudflare-one/policies/access/#selectors). While every possible selector is not listed here, the following lists specific outcomes that organizations using Cloudflare Access typically desire when building policies. This will help you understand how to achieve a specific outcome.
 
-- **Is user traffic coming over Cloudflare Gateway?**  
+- **Is user traffic coming over Cloudflare Gateway?**
   Guaranteeing that a user only accesses an application over our SWG, Cloudflare Gateway, is a great way to prevent unauthorized access due to phishing or credential theft. Additionally, you can ensure all traffic bound to the application is logged and filtered by Cloudflare Gateway.
 
   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/%20?). 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?**  
+- **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.
 
-- **Which identity service was used for authentication ?**  
+- **Which identity service was used for authentication ?**
   Similar to IdP groups and attributes, this “Login methods” selector asks which identity service was used; and, like IdP groups, this is better suited to an access group rather than a specific line item on an access policy. Login methods allow you to apply different policies to specific users who authenticated with certain identity providers. For example, you might only allow users who have authenticated with a consumer identity such as GitHub or LinkedIn to gain access if their authentication method included a hard token-based MFA.
 
   This is an atypical scenario, but if you do need to enable multiple IdPs for authentication, then you can use this selector to make sure users are authenticating with a specific service. The value of this requirement becomes clearer when dealing with multiple layered security policies, and need to define different levels of access based on the login.
 
-- **Individual or organizational emails**  
+- **Individual or organizational emails**
   All identity services provide an email address, which in many cases matches the individual’s username. Using an email in a policy can be useful when wanting to allow access to an entire domain of users, but they might authenticate via a consumer IdP that allows for any email. For example, you might only allow access for users who have authenticated via GitHub using their @company.com email address.
 
   Another good use of this selector is if you are managing a [list of emails](/cloudflare-one/policies/gateway/lists/) of users that might be high risk or have been blocked from a specific application. You can use an Exclude rule, with your list to ensure a subset of users cannot access an application.
 
-- **How did the user authenticate?**  
+- **How did the user authenticate?**
   When an identity provider authenticates a user and then redirects them back to Cloudflare, it includes information about what authentication method was used. This is typically sent as [Authentication Method Reference](https://datatracker.ietf.org/doc/html/rfc8176) data. Using this you can check if MFA was used and what type.
 
   This can be useful to define different levels of credential requirements for different applications. For example, a general company application might just require that MFA was used and not care how. But a really sensitive administration tool might require a FIDO2 hardware-based security key,and therefore explicitly deny access if only an OTP via SMS is used as part of the authentication process.
 
-- **What country is the request coming from?**  
+- **What country is the request coming from?**
   You can set rules based on the geographic lookup of the incoming request. This could be useful for restricting access to certain countries where you do business.
 
-- **What IP range is the request coming from?**  
-   You can set rules based on the IP range of the incoming request. This could be allowing access only from your corporate network IP ranges.
+- **What IP range is the request coming from?**
+  You can set rules based on the IP range of the incoming request. This could be allowing access only from your corporate network IP ranges.
 
-- **Is it possible to verify device or user information from a list?**  
+- **Is it possible to verify device or user information from a list?**
   Sometimes, you might want to grant or restrict access based on specific device or user characteristics that don't fit neatly into other categories. This is where [lists](/cloudflare-one/policies/gateway/lists/) come in handy: you can define or import a list of contractor emails, or a list of approved device serial numbers and use those as criteria within an Access policy. These lists can be updated manually or via our [API](/api/operations/zero-trust-lists-create-zero-trust-list), allowing for integration with other device or user management systems.
 
-- **Is the device's security posture adequate?**  
+- **Is the device's security posture adequate?**
   This is where the device client provides telemetry on the native device making the access request. It accomplishes this by performing device-level scans. Is the device’s hard drive encrypted? The agent can check if technologies like BitLocker or FileVault are active, in addition to checking for specific volume names. If you are protecting a sensitive application, or something that holds critical information, this is an effective requirement to enforce.
 
-- **Is the request being made by another process or application?**  
+- **Is the request being made by another process or application?**
   It is not always a real human on a device attempting to access an application. This makes it useful to leverage Cloudflare Access to manage communication to APIs by other software. The request may contain service tokens, mutual TLS certificates, and SSH certificates, which enables logins for automated processes and machine-to-machine communication. Using service auth options within Cloudflare also centralizes the storage and lifecycle management of these tokens and certificates.
 
-- **What does your third-party tool say about your device?**  
+- **What does your third-party tool say about your device?**
   Many organizations use other specialized tools for endpoint security, such as Crowdstrike, SentinelOne, or Microsoft Intune, to provide telemetry regarding the security posture of the device making the application request. Rather than require the user to navigate multiple UIs, you can integrate these tools into Cloudflare One via their API, and apply their insights into device posture attributes that can be enforced during an application login.
-  Note: Some third party device posture integrations can be used even when the user device doesn't have our agent installed. Instead, the third party integration matches the user based on email and provides information directly to Cloudflare.
+
+:::note[]
+Some third party device posture integrations can be used even when the user device doesn't have our agent installed. Instead, the third party integration matches the user based on email and provides information directly to Cloudflare.
+:::
 
 #### Additional settings
 
@@ -259,13 +266,13 @@ Before we examine how the two policies are defined, let's look at an Access Grou
 
 This access group is going to be used in both policies, and its sole goal is to identify what a "Secure Employee" is.
 
-| Name            | Secure Employees                                                                        |
-| :-------------- | :-------------------------------------------------------------------------------------- |
-| **Include**     |                                                                                         |
-| Azure AD Groups | "Full-Time Employees"                                                                   |
-| **Require**     |                                                                                         |
-| Azure AD Groups | "Completed security training"                                                           |
-| OS Version      | "Latest version of MacOS" "Latest version of Windows" "Latest Kernel version for Linux" |
+| Name            | Secure Employees                                                                          |
+| :-------------- | :---------------------------------------------------------------------------------------- |
+| **Include**     |                                                                                           |
+| Azure AD Groups | "Full-Time Employees"                                                                     |
+| **Require**     |                                                                                           |
+| Azure AD Groups | "Completed security training"                                                             |
+| OS Version      | "Latest version of MacOS", "Latest version of Windows", "Latest Kernel version for Linux" |
 
 This is a very simple Access Group, with just two group selectors. Note that because we are checking membership based on groups from a specific directory, it also implies that the user must have authenticated to that directory. It means in the future, if you move to another identity provider or change the group membership requirements for what defines a Full-Time Employee, you change just this Access Group once.
 
@@ -308,19 +315,21 @@ Although this policy is very similar to the first, it removes the requirement to
 
 But notice we now enable "Isolate Application." What does this mean? This forces all requests to the application to now be rendered on our RBI technology. RBI will prevent the wiki UX from loading directly in the end user's browser, and instead renders the content in a headless browser running on a server in Cloudflare’s global cloud network. Then, the results of that render are securely and efficiently communicated down to the end user’s browser. Because of this, the request is also sent via our SWG service, which enables you to write a policy that controls how users can interact with the wiki.
 
-| Gateway HTTP Policy: Isolate company applications for users on insecure devices |                            |
-| :------------------------------------------------------------------------------ | :------------------------- |
-| Action                                                                          | Isolate                    |
-| **Traffic**                                                                     |                            |
-| Domain in                                                                       | wiki.mycustomerexample.com |
-| Device Posture                                                                  |                            |
-| Passed device posture not in                                                    | Warp Check                 |
-| **Settings**                                                                    |                            |
-| Disable copy / paste                                                            | Yes                        |
-| Disable file downloads                                                          | Yes                        |
-| Disable file uploads                                                            | Yes                        |
-| Disable keyboard                                                                | Yes                        |
-| Disable printing                                                                | Yes                        |
+**Gateway HTTP Policy**
+
+| Isolate company applications for users on insecure devices |                            |
+| :--------------------------------------------------------- | :------------------------- |
+| Action                                                     | Isolate                    |
+| **Traffic**                                                |                            |
+| Domain in                                                  | wiki.mycustomerexample.com |
+| **Device Posture**                                         |                            |
+| Passed device posture not in                               | Warp Check                 |
+| **Settings**                                               |                            |
+| Disable copy / paste                                       | Yes                        |
+| Disable file downloads                                     | Yes                        |
+| Disable file uploads                                       | Yes                        |
+| Disable keyboard                                           | Yes                        |
+| Disable printing                                           | Yes                        |
 
 In the example above, the SWG policy is matching any traffic heading to your company wiki, then enforcing RBI (to match the ZTNA application policy) and then disabling all interaction with the wiki.