<a id="ccloud-console-access-networking"></a>

# Use the Confluent Cloud Console with Private Networking

In Confluent Cloud clusters with private networking, cluster endpoints used by some
Confluent Cloud workflows, including topic management and ksqlDB query management,
are not publicly accessible. For example, you cannot view Kafka topic
data/message from the Confluent Cloud Console running on a workstation outside of the
private network.

#### IMPORTANT
If you’ve configured access to Confluent resources as described in this
topic, but you still cannot view topics on private clusters in the
Confluent Cloud Console using Google Chrome and you get the message, “This
Cluster is protected by a private network”, you must enable the **Local
Network Access** setting in Chrome. Chrome recently added the Local Network
Access check as explained in [Google’s documentation](https://developer.chrome.com/blog/local-network-access).
For more information and the workaround, see the [Confluent Support
knowledge base article](https://support.confluent.io/hc/en-us/articles/43004389978388-Encountering-This-Cluster-is-protected-by-a-private-network-in-the-Confluent-Cloud-UI-when-using-Google-Chrome).

To view and manage your Confluent resources on a private network in
Confluent Cloud Console with a client computer, you have the following options:

* [Enable the Resource metadata access option](#ccloud-console-with-resource-management-access)

  If you only need to view topics and their metrics information, or if you need
  to use the Stream Lineage feature on the Confluent Cloud Console, you can enable the
  Resource metadata access option on the Confluent Cloud Console.

  This option does not allow you to view topics data/messages.
* [Create a connection to the network that hosts the private cluster endpoints](#ccloud-console-with-private-connection)

  For your Confluent clients (Confluent Cloud Console, REST API, CLI, Terraform, and
  Kafka API) from outside the private network to have access to the full
  functionality of Confluent Cloud, create and use a connection to the network that
  hosts the private endpoints.

  For example, to manage topics (create/update/delete), to produce to/consume
  from topics, or to manage ksqlDB queries, create a connection to the network
  that hosts the private cluster endpoints, and then update your DNS
  configuration for topics or ksqlDB endpoints to use that connection.

  #### NOTE
  This option involves configuring external components, such as proxies, SSH
  tunnels, and DNS in your network.

  Troubleshooting these additional components in your network is outside
  the Confluent Cloud support scope and is not covered by any support plan.

  See the [support note](../support.md#networking-not-covered) for more information.

If you do not use one of the above options, you do not have access to view and
manage topics and topics metadata in the Confluent Cloud Console.

<a id="ccloud-console-with-private-connection"></a>

## Create a connection to the network that hosts the private cluster endpoints

For single-cluster deployments, you can leverage managed services offered by your cloud provider — such as load balancers and gateways — to enable access to Confluent resources in private networking environments. These resources can then be managed and accessed using the Confluent Cloud Console or the Confluent CLI.

For large scale centralized architectures, you need a component with more advanced SNI routing than what the cloud provider load balancers and gateways can provide. NGINX remains the best technical solution.

Use the table below to find the right solution for Confluent Cloud service access.
You need to implement only one of the supported (check marked) solutions for
your configuration. For details, click the applicable scenario and complete the
required steps.

### Private link

| Scenario                                   | From an internet-based client   | From a VPC or VNet using VPN tunnel, Direct Connect, ExpressRoute, or Cloud Interconnect   | From a VPC or VNet                   |
|--------------------------------------------|---------------------------------|--------------------------------------------------------------------------------------------|--------------------------------------|
| [Proxy](#proxied-access)                   | ✔                               | N/A                                                                                        | No additional configuration required |
| [Reverse SSH tunnel](#reverse-ssh-tunnel)  | ✔                               | N/A                                                                                        | No additional configuration required |
| [Local DNS resolution](#local-dns-updates) | N/A                             | ✔                                                                                          | N/A                                  |

### Peering (VPC or VNet), Transit Gateway, or PNI

| Scenario                                   | From an internet-based client   | From a VPC or VNet using VPN tunnel, Direct Connect, ExpressRoute, or Cloud Interconnect   | From a VPC or VNet                   |
|--------------------------------------------|---------------------------------|--------------------------------------------------------------------------------------------|--------------------------------------|
| [Proxy](#proxied-access)                   | ✔                               | ✔                                                                                          | No additional configuration required |
| [Reverse SSH tunnel](#reverse-ssh-tunnel)  | ✔                               | ✔                                                                                          | No additional configuration required |
| [Local DNS resolution](#local-dns-updates) | N/A                             | N/A                                                                                        | N/A                                  |

<a id="proxied-access"></a>

### Configure a proxy

To enable access to Confluent services in a privately-networked Confluent Cloud cluster
from your local machine, you can use a proxy  ([NGINX](https://www.nginx.com/), [HAProxy](https://www.haproxy.org/),  [Envoy](https://www.envoyproxy.io/), or others). The proxy relays communication
between your local clients and Confluent Cloud resources.

Confluent Cloud hostnames must be maintained over a TCP proxy. Otherwise, TLS hostname
validation will fail, and TLS will not be established. You must have a DNS
record, or an entry in your `/etc/hosts` file, that points to the IP address of
the proxy instance that routes to the appropriate Confluent endpoint.

In the following example topology, the client runs outside of a VPC or VNet and
uses an NGINX proxy to connect to Confluent Cloud.

![Simplified proxy configuration](networking/images/nginx-proxy-configuration.png)

To install and configure the proxy, complete the following steps. The
configuration steps use NGINX as an example:

1. Provision a Virtual Machine (VM) in your VPC or VNet that is connected to
   Confluent Cloud.

   You can set it up with the default properties.
2. Install NGINX on an instance in the VPC or VNet connected to Confluent Cloud.

   If you are on Ubuntu or Debian, use the below command to install the latest
   version of NGINX onto your VM. If you are using RedHat, use the `yum`
   command.
   ```bash
   sudo apt update
   ```

   ```bash
   sudo apt install nginx
   ```
3. Test the NGINX configuration. NGINX checks the configuration for correct syntax and
   tries to open files referred to in the configuration:
   ```bash
   nginx -t
   ```

   The NGINX module path varies depending on the Linux distribution you’re
   using, for example, `/usr/lib/nginx/modules` or
   `/usr/lib64/nginx/modules`.

   If you get an error about `ngx_stream_module.so`:
   1. Locate the `ngx_stream_module.so` module.
   2. Add the following at the top of the NGINX configuration file
      (`/etc/nginx/nginx.conf`):
      ```text
      load_module /usr/lib/nginx/modules/ngx_stream_module.so;
      ```
   3. Re-test:
      ```bash
      nginx -t
      ```
4. Update the NGINX configuration file (`/etc/nginx/nginx.conf`) to use SNI
   from incoming TLS sessions for routing traffic to the appropriate servers on
   ports `443` and `9092`.

   Note: Do not replace `$targetBackend`. It is not a replaceable variable.
   ```text
   events {}
   stream {
     map $ssl_preread_server_name $targetBackend {
        default $ssl_preread_server_name;
    }

    server {
      listen 9092;

      proxy_connect_timeout 1s;
      proxy_timeout 7200s;

      resolver 127.0.0.53;

      proxy_pass $targetBackend:9092;
      ssl_preread on;
    }

    server {
      listen 443;

      proxy_connect_timeout 1s;
      proxy_timeout 7200s;

      resolver 127.0.0.53;

      proxy_pass $targetBackend:443;
      ssl_preread on;
    }

    log_format stream_routing '[$time_local] remote address $remote_addr'
                       'with SNI name "$ssl_preread_server_name" '
                       'proxied to "$upstream_addr" '
                       '$protocol $status $bytes_sent $bytes_received '
                       '$session_time';
    access_log /var/log/nginx/stream-access.log stream_routing;
   }
   ```

   1. To verify the resolver, run the following command on the NGINX host:
      ```bash
      nslookup <ConfluentCloud_BootstrapHostname> 127.0.0.53
      ```
   2. Check `/var/log/nginx/error.log` for any resolving issues using
      `127.0.0.53`.
   3. On lookup failure, reconfigure to use the cloud provider’s resolver:
      * For AWS: `resolver 169.254.169.253`
      * For Azure: `resolver 168.63.129.16`
      * For Google Cloud: `resolver 169.254.169.254`

      If you do need to switch resolvers, update `resolver` in
      BOTH `server` blocks that have `listen 9092` and `listen 443`.
5. Restart NGINX to pick up the latest configuration (`/etc/nginx/nginx.conf`).
   ```bash
   sudo systemctl restart nginx
   ```

   Verify that NGINX is running.
   ```bash
   sudo systemctl status nginx
   ```
6. Configure your DNS provider to resolve requests to Confluent Cloud to the proxy
   server.

   In the following example, the `/etc/hosts` file is updated to include the
   public IP address of your VM mapped to your Confluent Cloud cluster endpoint. This will
   route traffic that is destined for your Confluent Cloud through the proxy.

   Note that you update the `/etc/hosts` file of your local machine, not of
   the bastion host/proxy server.
   ```text
   ##
   # Host Database
   #
   # localhost is used to configure the loopback interface
   # when the system is booting.  Do not change this entry.
   ##
   127.0.0.1       localhost
   255.255.255.255 broadcasthost
   ::1             localhost
   <Public IP Address of VM instance> <Kafka-REST-Endpoint>
   <Public IP Address of VM instance> <Flink-private-endpoint>
   <Public IP Address of VM instance> <Flinkpls-private-endpoint>
   <Public IP Address of VM instance> <Schema-registry-private-endpoint>
   ```

   - `<Kafka-REST-Endpoint>` can be retrieved in the **Cluster settings** page
     on your Confluent Cloud Console.

     For retrieving the `<Kafka-REST-Endpoint>` for an AWS
     Enterprise cluster, see [Select a Kafka endpoint for AWS Enterprise clusters](#endpoint-selection-aws-enterprise).
   - `<Flink-private-endpoint>` can be retrieved as described in [Flink](../flink/concepts/flink-private-networking.md#flink-sql-private-networking).
   - For `<Flinkpls-private-endpoint>` (Flink language service), replace
     `flink` with `flinkpls` in the `<Flink-private-endpoint>` endpoint
     and specify that endpoint here.
   - `<Schema-registry-private-endpoint>` can be retrieved as described in
     [Enable Private Networking on Confluent Cloud for Schema Registry](../sr/fundamentals/sr-private-link.md#sr-ccloud-private-link).

   The example above resolves both the Kafka bootstrap server host and the Kafka
   REST host. The host addresses of the Kafka bootstrap server and the REST
   endpoint are the same, and only the port numbers differ.
7. For AWS Enterprise clusters only, set the cluster endpoint as
   described in [Select a Kafka endpoint for AWS Enterprise clusters](#endpoint-selection-aws-enterprise).
8. Go to the Confluent Cloud Console and verify that topics and ksqlDB query
   management are now visible under the **Topics** and **ksqlDB** tabs for your
   cluster.

<a id="reverse-ssh-tunnel"></a>

### Configure a reverse SSH tunnel

To connect to a privately-networked Confluent Cloud cluster from a local client on the
internet or on the on-premises network, you can use a reverse SSH tunnel.

At a high level, the reverse SSH tunnel captures all traffic going towards your
privately-networked Confluent Cloud cluster, then it routes that traffic over the
specified port through a bastion server deployed in your VPC/Vnet that has
access to your Confluent Cloud cluster.

1. Provision a bastion virtual machine (VM) in your VPC or VNet that is
   connected to Confluent Cloud with the SSH service.

   Upon “SSH public key source”, select an existing SSH key pair. Paste in your
   existing public key onto the “SSH public key” field. If you need to locate
   it, you can find it via going into your terminal and typing in the below
   command. Otherwise, create a new SSH public key pair.
   ```bash
   cat ~/.ssh/id_rsa.pub
   ```

   You can set up with the default values for the rest of the properties.
2. Test basic connectivity using the following command:
   ```bash
   sudo ssh <your_cloud_provider_username>@<public_ip_of_vm> -i ~/.ssh/id_rsa
   ```

   Your output should show a successful SSH into your VM.
3. Verify that the VMs have connectivity to your private endpoint using one of
   the following commands.

   `$BOOTSTRAP` can be retrieved in the **Cluster settings** on your
   Confluent Cloud Console.

   For retrieving the `$BOOTSTRAP` for an AWS Enterprise cluster,
   see [Select a Kafka endpoint for AWS Enterprise clusters](#endpoint-selection-aws-enterprise).
   * Create an HTTP connection to the specified bootstrap URL (`$BOOTSTRAP`):
     ```bash
     openssl s_client \
       -connect $BOOTSTRAP:9092 \
       -servername $BOOTSTRAP \
       -verify_hostname $BOOTSTRAP </dev/null 2>/dev/null | \
     grep -E 'Verify return code|BEGIN CERTIFICATE' | xargs
     ```

     If the return output is `-----BEGIN CERTIFICATE----- Verify return code: 0
     (ok)`,  connectivity to the bootstrap is confirmed.
   * Verify the connectivity to the specified bootstrap URL (`$BOOTSTRAP`):
     ```bash
     telnet $BOOTSTRAP 9092
     ```
4. Establish a reverse SSH tunnel from the client machine to the bastion VM for
   each Confluent Cloud component you are trying to connect from your local client.

   There are 3 different endpoints to reach different components of your
   Confluent Cloud cluster:
   * 443 is the Kafka REST API endpoint.
   * 9092 is the broker endpoint to direct traffic to from your local host.
   * ksqlDB endpoint.

   The Kafka REST endpoint (`<Kafka-REST-Endpoint>`) can be found in the
   **Cluster settings** page. The ksqlDB endpoint (`<ksqlDB-Endpoint>`) is
   displayed in the Confluent Cloud Console under **Cluster Settings** > **ksqlDB** >
   **Settings**.

   Note that the host addresses of the Kafka bootstrap server and the REST
   endpoint are the same, and only the port numbers differ.
   ```text
   sudo ssh -L 127.0.0.2:443:<Kafka-REST-Endpoint>:443 <username>@<VM-instance-public-DNS> -i ~/.ssh/id_rsa

   sudo ssh -L 127.0.0.3:443:<ksqlDB-Endpoint>:443 <username>@<VM-instance-public-DNS> -i ~/.ssh/id_rsa
   ```

   Note that these connections must be maintained in order for the tunnel to
   work. However, in cases, such as a system restart, the tunnel and the DNS
   loopback aliases may not persist.
5. Configure DNS to resolve traffic to the Confluent Cloud component endpoints.

   In the following example, `/etc/hosts` is updated to include the local IP
   addresses mapped to your Confluent Cloud cluster endpoints.
   ```text
   127.0.0.1 <Bootstrap-URL>
   127.0.0.2 <Kafka-REST-Endpoint>
   127.0.0.3 <ksqlDB-endpoint>
   ```
6. For AWS Enterprise clusters only, set the cluster endpoint as
   described in [Select a Kafka endpoint for AWS Enterprise clusters](#endpoint-selection-aws-enterprise).
7. Go to the Confluent Cloud Console and verify that topics are now visible under the
   **Topics** tab for your cluster.

<a id="local-dns-updates"></a>

### Configure your local DNS resolution

If connectivity cannot be established between the web browser and Confluent Cloud, DNS
provider updates are needed to route web browser requests to the Kafka REST API
endpoint and then to the private endpoint connected to Confluent Cloud.

For retrieving the Kafka bootstrap server for an AWS Enterprise
cluster, see [Select a Kafka endpoint for AWS Enterprise clusters](#endpoint-selection-aws-enterprise).

Note that the host addresses of the Kafka bootstrap server and the REST endpoint
are the same, and only the port numbers differ. In the table below,
`<Kafka-REST-Endpoint>` can resolve both the Kafka bootstrap server and the
Kafka REST host.

| Name                                                                                                                                                                                                                        | Value                         |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------|
| <Kafka-REST-Endpoint><br/><br/>Example: `lkc-12345-abcdef.westus2.azure.glb.confluent.cloud`                                                                                                                                | <Private endpoint IP address> |
| <KsqlEndpoint><br/><br/>Example: `pksqlc-54321-abcdef.westus2.azure.glb.confluent.cloud`                                                                                                                                    | <Private endpoint IP address> |
| <Flink-private-endpoint><br/><br/>Example: `flink.us-west-2.aws.private.confluent.cloud`                                                                                                                                    | <Private endpoint IP address> |
| <Flink-language-service-private-endpoint><br/><br/>Replace `flink` with `flinkpls` in the `<Flink-private-endpoint>`<br/>endpoint and use that endpoint.<br/><br/>Example: `flinkpls.us-west-2.aws.private.confluent.cloud` | <Private endpoint IP address> |
| <Schema-registry-private-endpoint><br/><br/>Example: `lsrc-xxxx.us-west-2.aws.private.confluent.cloud` or `lsrc-1234.domxxxxxx-us-west-2.aws.private.confluent.cloud`                                                       | <Private endpoint IP address> |

When DNS update is complete, go to the Confluent Cloud Console and verify that topics
are now visible under the **Topics** tab for your cluster.

For Enterprise clusters in AWS, you will have to follow the
instructions to set the endpoint to be used by the Confluent Cloud Console found
here as described in [Set the endpoint to be used by the Confluent Cloud Console for AWS Enterprise clusters](#dual-network-endpoint-aws).

<a id="endpoint-selection-aws-enterprise"></a>

### Select a Kafka endpoint for AWS Enterprise clusters

Retrieve the Kafka endpoint for an AWS Enterprise cluster in the
Confluent Cloud Console.

1. When you initially access the **Cluster settings** page of an AWS
   Enterprise cluster in the Confluent Cloud Console, you are prompted to
   select the default networking endpoint.
2. Close the dialog box that prompts you to select the default networking
   endpoint.
3. In the **Cluster settings** page, select a `<Kafka-REST-Endpoint>` that is
   associated with an active (in the **Ready** state) networking configuration.
   ![Selecting a Kafka REST endpoint on the Cluster Settings page](networking/images/dual-network-select-default.png)

   To check if a network configuration is active, browse to the **Network
   management** page and check the **Status** column of the gateway. In an
   environment, all the serverless gateways can access all the
   Enterprise clusters. So you can pick any active gateway to get the
   Kafka endpoint.

<a id="dual-network-endpoint-aws"></a>

### Set the endpoint to be used by the Confluent Cloud Console for AWS Enterprise clusters

For an Enterprise type cluster on AWS, you must set the cluster
endpoint to be used by the Confluent Cloud Console for access to full console
functionality.

When you first access an AWS Enterprise cluster in the
Confluent Cloud Console, you are prompted to select the default networking endpoint.

![Prompt to select the default networking endpoint for an Enterprise cluster](networking/images/dual-network-no-default.png)

#### NOTE
Regardless of the endpoint selected, both PNI and PrivateLink Attachment endpoints are
always listed for the cluster.

Select the `<Kafka-REST-Endpoint>` that is associated with the PNI gateway
or PrivateLink Attachment. This will be the endpoint that allows you access to the cluster
details in the Confluent Cloud Console. The endpoint that includes `glb` in the URL
is the endpoint for the PNI networking type.

![Selecting the Kafka REST endpoint associated with the PNI gateway or PrivateLink Attachment](networking/images/dual-network-select-default.png)

When you make a selection, you will see an error message that the endpoint is
not available if you haven’t set up the proxy and configured your DNS
resolution. This is expected.

When you complete the full setup, you will get the message that the endpoint is
ready to use. At this point, setup is complete and you will be able to access
all functionality in the Confluent Cloud Console.

![Confirmation that the selected networking endpoint is ready to use](networking/images/dual-network-select-cpog.png)

<a id="ccloud-console-with-resource-management-access"></a>

## Enable or disable the Resource metadata access option

The Resource metadata access option enables you to connect to the clusters with
private networking to view resources. Specifically, the following features are
enabled when you turn on the option:

- Viewing topics metadata and configuration

  Avoid turning on this option if topic names are considered sensitive.
- Viewing consumer lags and other topic-level metrics
- Viewing and configuring Schema Registry
- Using Stream Lineage
- Listing existing topics during connector creation

You can toggle the option at the cluster level or at the organization level. The
cluster-level toggle overrides the organization-level toggle.

Note that the Resource metadata access option only controls access on the
Confluent Cloud Console. Resource metadata is not accessible using Confluent Cloud APIs,
Confluent CLI, or Terraform even when the option is enabled.

The Resource metadata access option is read-only. Even if you have the
DeveloperWrite access or above on a topic and have the Resource metadata access
option enabled, you cannot create, edit, or delete topics. Management operations
(create, update, and delete) still require setting up a proxy or SSH as
described in [Create a connection to the network that hosts the private cluster endpoints](#ccloud-console-with-private-connection).

Before you enable the Resource metadata access option, review the following
information:

* You access topic metadata (name and settings) on the Confluent Cloud Console over
  the public network using the TLS-enabled connections.

  No one outside of your organization will be able to see the topic information,
  and the information will be protected by the RBAC permissions you configure.

  As summarized in the below table, topic and Stream Lineage views are only
  available to users with the following roles: OrganizationAdmin,
  EnvironmentAdmin, DataDiscovery, DataSteward, and environment- or
  organization-scoped Operator.

  Cluster-level roles, such as cluster admin or cluster metric viewer, do not have
  read access.

  | Role                                                                                                 | Scope                     | READ Allowed   |
  |------------------------------------------------------------------------------------------------------|---------------------------|----------------|
  | [OrganizationAdmin](../security/access-control/rbac/predefined-rbac-roles.md#organizationadmin-role) | Organization              | Yes            |
  | [EnvironmentAdmin](../security/access-control/rbac/predefined-rbac-roles.md#environmentadmin-role)   | Environment               | Yes            |
  | [DataDiscovery](../security/access-control/rbac/predefined-rbac-roles.md#datadiscovery-role)         | Environment               | Yes            |
  | [DataSteward](../security/access-control/rbac/predefined-rbac-roles.md#datasteward-role)             | Environment               | Yes            |
  | [Operator](../security/access-control/rbac/predefined-rbac-roles.md#operator-role)                   | Organization, Environment | Yes            |
  | [Operator](../security/access-control/rbac/predefined-rbac-roles.md#operator-role)                   | Cluster                   | No             |
* The topic data will still not be accessible over the internet.
* Topic-level DENY ACLs will not prevent users from reading topic metadata (name
  and settings). For more information about Kafka ACLs, see [ACL Overview](../security/access-control/acls/overview.md#acl-manage).
* The RBAC roles that allow users to read  topic metadata for individual topics
  (such as DeveloperRead and ResourceOwner), or the roles that allow users to
  read topic metadata on individual clusters (such as CloudClusterAdmin) will
  not be sufficient to use this feature. See the list below for roles that
  enable this feature.

To enable or disable the Resource metadata access:

1. Log into Confluent Cloud as an administrator with the OrganizationAdmin role.

   Only the OrganizationAdmin role has the permission to toggle the Resource
   metadata access both at the cluster level and organization level.
2. Make sure the Stream Governance package is turned on in your Confluent Cloud
   environment.

   You can use any package of Stream Governance, including the free Essentials
   package. For more information about Stream Governance, see [Stream Governance on Confluent Cloud](../stream-governance/index.md#cloud-dg).
3. Enable or disable **Resource metadata access**.
   * To enable or disable the option at the cluster level, toggle **Resource
     Metadata Access** on or off in the **Security** tab on the **Cluster
     Settings** page.

     You can also enable **Resource metadata access** when you create a cluster
     at the Networking setup step.
   * To enable or disable the option at the organization level, toggle
     **Resource Metadata Access** on or off on the **Organizations** page.
4. If you enabled the **Resource metadata access** option, navigate to your
   cluster’s topics and Stream Lineage pages to view them.

## Related content

- [Enable Private Networking with Confluent Cloud for Apache Flink](../flink/operate-and-deploy/private-networking.md#flink-sql-enable-private-networking)
- Video: [Flink Queries on Dedicated PrivateLink Kafka Clusters in Confluent Cloud](https://www.youtube.com/watch?v=IX6dcgDnVtk)