IP Filtering on Confluent Cloud

IP Filtering is an authorization feature that provides Confluent Cloud organizations with enhanced security by allowing management of your resources only from trusted source networks. You can create IP filters for your Confluent Cloud organization that allow inbound (or ingress) network traffic based on the included IP groups (lists of CIDR blocks) defining your trusted source networks. All incoming API requests to use the Confluent Cloud resource management APIs (api.confluent.cloud) that originate from IP addresses not included in your IP filters are denied.

IP Filtering Overview

By default, Confluent Cloud resources are accessible from any source IP address. You can use IP Filtering to restrict access for managing your Confluent Cloud resources to only trusted source networks and enhancing security.

Some of the benefits of using IP Filtering in Confluent Cloud include:

  • Reduced attack surface for your Confluent Cloud resources: IP Filtering reduces the attack surface for your Confluent Cloud resources by restricting access to only trusted source networks.
  • Reduced risk of unauthorized access: IP Filtering reduces the risk of unauthorized access to your Confluent Cloud resources by restricting access to only trusted source networks. IP Filtering provides a second layer of protection for your Confluent Cloud resources if a credential for for a user or service account is compromised.
  • Enhanced visibility into suspicious activity: IP Filtering provides enhanced visibility into suspicious activity by restricting access to only trusted source networks. If someone attempts to access your Confluent Cloud resources from IP addresses not covered by your IP filters, your Confluent Cloud audit log records the attempt, and you can take appropriate action to secure your Confluent Cloud resources.

The key components of IP Filtering that you should understand are:

  • IP group: The list of CIDR blocks specifying the trusted source networks. IP groups are used to create IP filters that control access to Confluent Cloud resources.

  • IP filter: The set of IP groups associated with a resource group. Currently, only one resource group (“management”) is available, and it is the default resource group for all IP filters. When an IP filter is applied to “management” resource group, creating a connector by executing a KSQL statement fails.

  • Resource group: The scope of resources covered by an IP filers. Currently, only one resource group, covering Resource Management (“management”) is available. This “management” resource group covers all managment operations requested from the resource management APIs available through api.confluent.cloud. For a list of supported APIs, click the following link to expand and display the list, or click the link again to collapse the list.

    Resource management APIs (api.confluent.cloud) - Supported by IP Filtering
    • ORG API (V2)
      • Organizations (org/v2)
      • Environments (org/v2)
    • IDENTITY ACCESS MANAGEMENT (v2)
      • API Key (iam/v2)
      • Users (iam/v2)
      • Service Accounts (iam/v2)
      • Invitations (iam/v2)
      • IP Groups (iam/v2)
      • IP Filters (iam/v2)
      • Role Bindings (iam/v2)
      • Identity Providers (iam/v2)
      • Jwks (iam/v2)
      • Identity Pools (iam/v2)
      • Group Mappings (iam/v2/sso)
    • BRING YOUR OWN KEY (BYOK) MANAGEMENT (V1)
      • Keys (byok/v1)
    • CLUSTER MGMT FOR KAFKA (V2)
      • Clusters (cmk/v2)
    • CLUSTER MGMT FOR SCHEMA REGISTRY (V2)
      • Regions (srcm/v2)
      • Clusters (srcm/v2)
    • COMPUTE POOL MGMT FOR FLINK (V2)
      • Compute Pools (fcpm/v2)
      • Regions (fcpm/v2)
    • CLUSTER MGMT FOR KSQLDB (V2)
      • Clusters (ksqldbcm/v2)
    • CONNECT API (V1)
      • Connectors (connect/v1)
      • Lifecycle (connect/v1)
      • Status (connect/v1)
      • Managed Connector Plugins (connect/v1)
      • Presigned Urls (connect/v1)
    • STREAM SHARING API (V1)
      • Provider Shared Resources (cdx/v1)
      • Provider Shares (cdx/v1)
      • Consumer Shared Resources (cdx/v1)
      • Consumer Shares (cdx/v1)
      • Shared Tokens (cdx/v1)
      • Opt Ins (cdx/v1)
    • STREAM DESIGNER API (V1)
      • Pipelines (sd/v1)
    • NETWORKING (V1)
      • Networks (networking/v1)
      • Peerings (network/v1)
      • Transit Gateway Attachments (networking/v1)
      • Private Link Accesses (networking/v1)
      • Network Link Services (networking/v1)
      • Network Link Endpoints (networking/v1)
      • Network Link Service Associations (networking/v1)
      • IP Addresses (networking/v1)
      • Private Link Attachments (networking/v1)
      • Private Link Attachment Connections (networking/v1)
    • NOTIFICATIONS API (V1)
      • Subscriptions (notifications/v1)
      • Integrations (notifications/v1)
      • Notification Types (notifications/v1)
    • SECURITY TOKEN SERVICE (V1)
      • OAuth Tokens (sts/v1)
    • SERVICE QUOTA API (V1)
      • Applied Quotas (service-quota/v1)
      • Scopes (service-quota/v1)
    • KAFKA QUOTA (V1)
      • Client Quotas (kafka-quotas/v1)
    • BILLING API (V1)
      • Costs (billing/v1)
    • PARTNER API (V2)
      • Entitlements (partner/v2)
      • Organizations (partner/v2)
      • Signup (partner/v2)

Example

Assume that Julia manages the Confluent Cloud organization for her company and wants to ensure that management operations can be performed only from trusted network locations.

  1. Julia collects a list of the CIDR blocks that represent the trusted network locations for her company.
  2. She creates an IP group for each trusted network location, naming each IP group to match the trusted network location. For example, she creates an IP group named “SF Office” for the trusted network location of her company’s San Francisco office. And, another IP group named “Corp VPN” for the trusted network location of her company’s corporate VPN.
  3. Next, Julia creates an IP filter and adds the IP groups for the trusted network locations to the IP filter. She names the IP filter “Allow Corporate Offices and VPN” to indicate that it permits access from the corporate location networks and the VPN. She also associates the IP filter with the “management” resource group, which restricts the operations to the management of Confluent Cloud resources.
  4. Finally, Julia verifies that the IP filter is working as expected by doing the following:
    • Attempt to access her Confluent Cloud resources from IP address included in her IP filters.
    • Attempt to access her Confluent Cloud resources from IP address not included in her IP filters. These attempts are denied.
    • Check the Confluent Cloud audit log to see that her tests to access her Confluent Cloud resources from IP addresses not included in her IP filters are denied, as expected, and are recorded in the audit log.

Steps to implement IP filtering

To use the IP Filtering feature, you must perform the following steps:

  1. Create IP groups that represent trusted source networks.

  2. Create an IP filter that associates the allowed IP groups with the “management” resource group.

    Once filters are created, all incoming API requests to use the Confluent Cloud API (api.confluent.cloud) that do not originate from IP addresses in your trusted network locations are denied.

  3. Verify that the IP filter is working as expected. You can verify that the IP filter is working as expected by attempting to access your Confluent Cloud resources from an IP address not included in your IP filters. If the IP filter is working as expected, the attempt is denied, and the Confluent Cloud audit log records the attempt.

Limitations

IP Filtering currently has the following limitations:

  • Protecting access to data in Kafka topics, ksqlDB databases, Flink compute pools, and Schema Registry schemas is not supported.
  • Only one resource group (“management”) is currently available. The “management” resource group covers the management of Confluent Cloud resources using the resource management APIs (api.confluent.cloud).
  • When an IP filter is applied to “management” resource group, creating a connector by executing a KSQL statement fails.
  • Only IPv4 CIDR blocks are supported.

Prerequisites

To use IP Filtering, you must have the following:

  • A Confluent Cloud account with the OrganizationAdmin role. If you do not have these permissions, the Confluent Cloud Console for IP Filtering is unavailable.
  • A list of IPv4 CIDR blocks representing the trusted source networks that can access Confluent Cloud resources.

To use the confluent iam ip-filter and confluent iam ip-group CLI commands, you must have the following:

  • Confluent CLI version 3.43.0 or later.

Related content