[ZT] Infrastructure access

src/content/docs/cloudflare-one/account-limits.mdx

@@ -24,6 +24,7 @@ This page lists the default account limits for rules, applications, fields, and
 | Rules count per application | 1,000 |
 | Rules count per group       | 1,000 |
 | Domains per application     | 5     |
+| Infrastructure targets      | 300   |
 
 ## Gateway
 
@@ -75,5 +76,6 @@ This page lists the default account limits for rules, applications, fields, and
 | mTLS certificates name | 350             |
 | Service token name     | 350             |
 | IdP name               | 350             |
+| Target name            | 255             |
 | Application URL        | 63              |
 | Team domain            | 63              |

src/content/docs/cloudflare-one/applications/non-http/browser-rendering.mdx

@@ -0,0 +1,26 @@
+---
+pcx_content_type: how-to
+title: Browser-rendered terminal
+sidebar:
+  order: 11
+
+---
+
+Cloudflare can render certain non-web applications in your browser without the need for client software or end-user configuration changes. Cloudflare currently supports rendering a terminal for SSH and VNC connections in a user's browser.
+
+:::note
+You can only enable browser rendering on domains and subdomains, not for specific paths.
+:::
+
+## Enable browser rendering
+
+To enable browser rendering:
+
+1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**.
+2. Locate the SSH or VNC application you created when [connecting the server to Cloudflare](/cloudflare-one/connections/connect-networks/use-cases/ssh/). Select **Configure**.
+3. In the **Policies** tab, ensure that only **Allow** or **Block** policies are present. **Bypass** and **Service Auth** are not supported for browser-rendered applications.
+4. In the **Settings** tab, scroll down to **Additional settings**.
+5. For **Browser rendering**, choose *SSH* or *VNC*.
+6. Select **Save application**.
+
+When users authenticate and visit the URL of the application, Cloudflare will render a terminal in their browser.

src/content/docs/cloudflare-one/applications/non-http/cloudflared-authentication.mdx

@@ -1,6 +1,6 @@
 ---
 pcx_content_type: how-to
-title: Connect using cloudflared
+title: Cloudflared authentication
 sidebar:
   order: 11
 
@@ -12,7 +12,7 @@ Users log in to the application by running a `cloudflared access` command in the
 
 :::note
 
-Automated services should only authenticate with `cloudflared` if they cannot use a [service token](/cloudflare-one/identity/service-tokens/). Cloudflared authentication relies on WebSockets to establish a connection. WebSockets have a known limitation where persistent connections may close unexpectedly. We recommend either a [Service Auth policy](/cloudflare-one/policies/access/#service-auth) or using [Warp to Tunnel routing](/cloudflare-one/applications/non-http/) in these instances. 
+Automated services should only authenticate with `cloudflared` if they cannot use a [service token](/cloudflare-one/identity/service-tokens/). Cloudflared authentication relies on WebSockets to establish a connection. WebSockets have a known limitation where persistent connections may close unexpectedly. We recommend either a [Service Auth policy](/cloudflare-one/policies/access/#service-auth) or using [Warp to Tunnel routing](/cloudflare-one/applications/non-http/) in these instances.
 :::
 
 ## Setup

src/content/docs/cloudflare-one/applications/non-http/index.mdx

@@ -1,44 +1,46 @@
 ---
-pcx_content_type: how-to
-title: Add non-HTTP applications
+pcx_content_type: concept
+title: Non-HTTP applications
 sidebar:
   order: 2
 
 ---
 
-You can secure non-HTTP applications by [connecting your private network](/cloudflare-one/connections/connect-networks/private-net/) to Cloudflare. Users reach the application by installing the Cloudflare WARP client on their device and enrolling in your Zero Trust organization. Remote devices will be able to 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.
+Cloudflare offers both client-based and clientless ways to grant secure access to non-HTTP applications.
 
-## Setup
+:::note
+Non-HTTP applications require [connecting your private network](/cloudflare-one/connections/connect-networks/private-net/) to Cloudflare. For more details, refer to our [Replace your VPN](/learning-paths/replace-vpn/connect-private-network/) implementation guide.
+:::
 
-For a comprehensive overview of how to connect a private network, refer to our implementation guide:
+## WARP client
 
-* [Replace your VPN](/learning-paths/replace-vpn/connect-private-network/)
+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.
 
-To connect to an application over a specific protocol, refer to these tutorials:
+You can optionally add the application to [Access for Infrastructure](/cloudflare-one/applications/non-http/infrastructure-apps/) for an additional layer of control and visibility over how users access non-HTTP applications. Benefits of using Access for Infrastructure include:
+- 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.
+- Export SSH command logs through a storage service or SIEM solution.
 
-* [Connect over SSH with WARP to Tunnel](/cloudflare-one/connections/connect-networks/use-cases/ssh/#connect-to-ssh-server-with-warp-to-tunnel)
-* [Connect over SMB with WARP to Tunnel](/cloudflare-one/connections/connect-networks/use-cases/smb/#connect-to-smb-server-with-warp-to-tunnel)
-* [Connect over RDP with WARP to Tunnel](/cloudflare-one/connections/connect-networks/use-cases/rdp/#connect-to-rdp-server-with-warp-to-tunnel)
+## Clientless access
 
-## Enable browser rendering
+Clientless access methods are suited for organizations that cannot deploy the WARP client or need to support third-party contractors. Clientless access requires onboarding a domain to Cloudflare and configuring a public hostname in order to make the server reachable. Command logging is not supported, and user email prefixes must match their username on the server.
 
-Cloudflare can render certain non-web applications in your browser without the need for client software or end-user configuration changes. Cloudflare currently supports rendering a terminal for SSH and VNC connections in a user's browser.
-
-:::note
+### Browser-based terminal
 
+Cloudflare's [browser-based terminal](/cloudflare-one/applications/non-http/browser-rendering/) allows users to connect over SSH and VNC without any configuration. When users visit the public hostname URL (for example, `https://ssh.example.com`) and log in with their Access credentials, Cloudflare will render a terminal in their browser.
 
-You can only enable browser rendering on domains and subdomains, not for specific paths.
-
+### Cloudflared authentication (legacy)
 
+:::note
+Not recommended for new deployments.
 :::
 
-To enable browser rendering:
+Users can log in to the application by installing `cloudflared` on their device and running a hostname-specific command in their terminal. For more information, refer to [Cloudflared authentication](/cloudflare-one/applications/non-http/cloudflared-authentication/).
 
-1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**.
-2. Locate the SSH or VNC application you created when [connecting the server to Cloudflare](/cloudflare-one/connections/connect-networks/use-cases/ssh/). Select **Configure**.
-3. In the **Policies** tab, ensure that only **Allow** or **Block** policies are present. **Bypass** and **Service Auth** are not supported for browser-rendered applications.
-4. In the **Settings** tab, scroll down to **Additional settings**.
-5. For **Browser rendering**, choose *SSH* or *VNC*.
-6. Select **Save application**.
+## Related resources
+
+To connect to an application over a specific protocol, refer to these tutorials:
 
-When users authenticate and visit the URL of the application, Cloudflare will render a terminal in their browser.
+* [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/)

src/content/docs/cloudflare-one/applications/non-http/infrastructure-apps.mdx

@@ -0,0 +1,140 @@
+---
+pcx_content_type: how-to
+title: Add an infrastructure application
+sidebar:
+  order: 2
+	badge:
+		text: Beta
+---
+
+import { Badge, Details, Tabs, TabItem, Render } from "~/components"
+
+Access for Infrastructure allows you to have granular control over how users access individual servers, clusters, or databases in your private network. By adding an infrastructure application to Cloudflare Access, you can configure how users authenticate to the resource as well as specify the ports, protocols, and usernames that they can connect with. Access and command logs ensure regulatory compliance and provide visibility into user activity in case of a security breach.
+
+<Render file="access/short-lived-certs-intro" params={{ intro: "Furthermore, SSH applications replace" }} />
+
+## Prerequisites
+
+- [Connect your private network](/cloudflare-one/connections/connect-networks/private-net/) to Cloudflare using `cloudflared` or WARP Connector.
+- [Deploy the WARP client](/cloudflare-one/connections/connect-devices/warp/deployment/) on user devices in Gateway with WARP mode.
+
+## 1. Add a target
+
+<Tabs>
+<TabItem label="Dashboard">
+1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Network** > **Targets**.
+2. Select **Add a target**.
+3. In **Target hostname**, enter a user-friendly name for the target resource. We recommend using the server hostname, for example `production-server`. The hostname does not need to be unique and can be reused for multiple targets.
+	<Details header="Format restrictions">
+			- Case insensitive
+			- Contain no more than 255 characters
+			- Contain only alphanumeric characters, `-`, or `.` (no spaces allowed)
+			- Start and end with an alphanumeric character
+	</Details>
+4. In **IP addresses**, enter the private IPv4 and/or IPv6 address of the target resource. If the IP address overlaps across multiple private networks, select the [virtual network](/cloudflare-one/connections/connect-networks/private-net/cloudflared/tunnel-virtual-networks/) where the target resource is located.
+:::note
+Public IPs are not currently supported.
+:::
+5. Select **Add target**.
+</TabItem>
+<TabItem label="API">
+
+</TabItem>
+</Tabs>
+
+Next, create an infrastructure application to secure the target.
+
+## 2. Add an infrastructure application
+
+<Tabs>
+<TabItem label="Dashboard">
+1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**.
+2. Select **Add an application**.
+3. Select **Infrastructure**.
+4. Enter any name for the application.
+5. In **Target criteria**, select the target hostname(s) that will represent the application. The application definition will apply to all targets that share the selected hostname.
+6. Enter the **Protocol** and **Port** that will be used to connect to the server.
+7. (Optional) If a protocol runs on more than one port, select **Add new target criteria** and reconfigure the same target hostname and protocol with a different port number.
+8. Select **Next**.
+</TabItem>
+<TabItem label="API">
+
+</TabItem>
+</Tabs>
+
+:::note
+Access for Infrastructure only supports assigning one protocol per port. You can reuse a port/protocol pairing across infrastructure applications, but the port cannot be reassigned to another protocol.
+:::
+
+## 3. Add a policy
+
+To secure your targets, configure a policy that defines who can connect and how they can connect:
+
+1. Enter any name for your policy.
+2. Create a rule that matches the users who are allowed to reach the targets. For more information, refer to  [Access policies](/cloudflare-one/policies/access/).
+3. In **Connection context**, enter the usernames that users can log in as (for example, `root` or `ec2-user`).
+4. Select **Add application**.
+
+A summary page will show the configured targets and policies for this application.
+
+:::note
+Gateway [network policies](/cloudflare-one/policies/gateway/network-policies/) take precedence over infrastructure policies. For example, if you block port `22` for all users in Gateway, then no one can SSH over port `22` to your targets.
+:::
+
+### Selectors
+
+The following [Access policy selectors](/cloudflare-one/policies/access/#selectors) are available for securing infrastructure applications:
+- Email
+- Emails ending in
+- SAML group
+- Country
+- Authentication method
+- Device posture
+- Azure group, GitHub organization, Google Workspace group, Okta group
+
+## Connect as a user
+
+### Display available targets
+
+Users can use  `warp-cli` to display a list of targets they can access. On the WARP device, open a terminal and run the following command:
+
+```sh
+warp-cli target list
+```
+
+```sh output
+example output table here
+```
+
+### Connect over SSH
+
+Users can use any SSH client to connect to the target resource, as long as they are logged into the WARP client on their device. Users do not need to modify any existing SSH configs. For example, to SSH from a terminal:
+
+```sh
+ssh <username>@<target IP address>
+```
+
+If your organization has configured a [private DNS resolver](/cloudflare-one/policies/gateway/resolver-policies/), then this command may look like:
+
+```sh
+ssh <username>@<target hostname>
+```
+
+Cloudflare will authenticate, proxy, and optionally encrypt and record all SSH traffic through Gateway.
+
+### Connect to different VNET
+
+To connect to targets that are in different VNETS, users will need to [switch their connected virtual network](/cloudflare-one/connections/connect-networks/private-net/cloudflared/tunnel-virtual-networks/#connect-to-a-virtual-network) in the WARP client.
+
+:::note
+If a user is connected to a target in VNET-A and needs to connect to a target in VNET-B, swithing their VNET will not break any existing connections to targets within VNET-A. At present, connections are maintained between VNETs.
+:::
+
+## View logs
+
+## Revoke a user's session
+
+To revoke a user's access to all infrastructure applications and targets, you can either [revoke the user from Zero Trust](/cloudflare-one/identity/users/session-management/#per-user) or revoke their device. There is currently no way to revoke a user's session for a specific resource.
+
+## Delete an infrastructure application
+

src/content/docs/cloudflare-one/connections/connect-devices/agentless/index.mdx

@@ -10,7 +10,7 @@ If you are unable to install the WARP client on your devices (for example, Windo
 
 * **[Gateway DNS policies](/cloudflare-one/connections/connect-devices/agentless/dns/)**
 * **[Gateway HTTP policies](/cloudflare-one/connections/connect-devices/agentless/pac-files/)** without user identity and device posture
-* **[Access policies](/cloudflare-one/policies/access/)** without device posture for [web applications](/cloudflare-one/applications/configure-apps/) and [browser-rendered](/cloudflare-one/applications/non-http/#enable-browser-rendering) SSH and VNC connections
+* **[Access policies](/cloudflare-one/policies/access/)** without device posture for [web applications](/cloudflare-one/applications/configure-apps/) and [browser-rendered](/cloudflare-one/applications/non-http/browser-rendering/) SSH and VNC connections
 * **[Remote Browser Isolation](/cloudflare-one/policies/browser-isolation/)** via an [Access policy](/cloudflare-one/policies/access/isolate-application/), [prefixed URLs](/cloudflare-one/policies/browser-isolation/setup/clientless-browser-isolation/), or a [non-identity on-ramp](/cloudflare-one/policies/browser-isolation/setup/non-identity/)
 * **[Cloud Access Security Broker (CASB)](/cloudflare-one/applications/scan-apps/)**
 * **[Data Loss Prevention (DLP)](/cloudflare-one/applications/scan-apps/casb-dlp/)** for SaaS applications integrated with Cloudflare CASB

src/content/docs/cloudflare-one/connections/connect-networks/use-cases/ssh.mdx

@@ -138,4 +138,4 @@ Users can connect from their device by [authenticating through `cloudflared`](#n
 
 End users can connect to the SSH server without any configuration by using Cloudflare's browser-based terminal. When users visit the public hostname URL (for example, `https://ssh.example.com`) and log in with their Access credentials, Cloudflare will render a terminal in their browser.
 
-To enable, refer to [Enable browser rendering](/cloudflare-one/applications/non-http/#enable-browser-rendering).
+To enable, refer to [Browser-rendered terminal](/cloudflare-one/applications/non-http/browser-rendering/).

src/content/docs/cloudflare-one/identity/users/short-lived-certificates.mdx

@@ -10,9 +10,7 @@ head:
 
 import { Render } from "~/components";
 
-Cloudflare Access can replace traditional SSH key models with short-lived certificates issued to your users based on the token generated by their Access login. In traditional models, users generate a keypair and commit their public key into an infrastructure management tool, like [Salt](https://github.com/saltstack/salt), or otherwise upload it to an administrator. These keys can remain unchanged for months or years.
-
-Cloudflare Access removes the burden on the end user of generating a key, while also improving security of access to infrastructure with ephemeral certificates.
+<Render file="access/short-lived-certs-intro" params={{ intro: "Cloudflare Access can replace" }} />
 
 ## 1. Secure the server behind Cloudflare Access
 
@@ -83,7 +81,7 @@ Match host vm.example.com exec "/usr/local/bin/cloudflared access ssh-gen --host
 
 ### Connect through a browser-based terminal
 
-End users can connect to the SSH session without any configuration by using Cloudflare's browser-based terminal. Users visit the URL of the application and Cloudflare's terminal handles the short-lived certificate flow. To enable, refer to [Enable browser rendering](/cloudflare-one/applications/non-http/#enable-browser-rendering).
+End users can connect to the SSH session without any configuration by using Cloudflare's browser-based terminal. Users visit the URL of the application and Cloudflare's terminal handles the short-lived certificate flow. To enable, refer to [Browser-rendered terminal](/cloudflare-one/applications/non-http/browser-rendering/).
 
 ---
 

src/content/partials/cloudflare-one/access/self-hosted-policy.mdx

@@ -5,7 +5,7 @@
 
 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 rule.
+1. Enter any name for your policy.
 
 2. Specify a policy [action](/cloudflare-one/policies/access/#actions).
 

src/content/partials/cloudflare-one/access/self-hosted-settings.mdx

@@ -8,6 +8,6 @@ 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/#enable-browser-rendering)
+* [Browser rendering](/cloudflare-one/applications/non-http/browser-rendering/)
 
 To finish configuring the application, select **Add application**.

src/content/partials/cloudflare-one/access/short-lived-certs-intro.mdx

@@ -0,0 +1,9 @@
+---
+params:
+	- intro
+
+---
+
+import { Markdown } from "~/components"
+
+{props.intro} traditional SSH keys with short-lived certificates issued to your users based on the token generated by their Access login. In traditional models, users generate a keypair and commit their public key into an infrastructure management tool, like [Salt](https://github.com/saltstack/salt), or otherwise upload it to an administrator. These keys can remain unchanged for months or years. Cloudflare Access removes the burden on the end user of generating a key, while also improving security of access to infrastructure with ephemeral certificates.