IP Filtering on Confluent Cloud

IP filtering is an authorization feature that strengthens the security of your Confluent Cloud organization by allowing you to limit access to your Confluent Cloud resources to only trusted source networks. Create IP filters for your Confluent Cloud organization to secure your resources by:

• Defining IP groups, or lists of CIDR blocks, which are allowed to make inbound requests.

• Defining IP filters that block requests from excluded IP addresses.

If a credential for a user or service account is compromised, IP filtering provides a second layer of protection for your Confluent Cloud resources. This additional protection reduces the risk of unauthorized access to your resources. If someone attempts to access your Confluent Cloud resources from IP addresses not covered by your IP filters, the request is denied and your Confluent Cloud audit log records the attempt.

IP filtering applies only to requests from public networks. It has no effect on requests that arrive over customer-configured private networks.

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

• IP group: A named 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: A set of IP groups associated with a resource scope and a set of operation groups. IP filters control which client networks can be used to access your resources.

• Resource scope: The scope of resources covered by IP filters. Two resource scopes are available:

  • Organization: Covers all resources in the Confluent Cloud organization.

  • Environment: Covers all resources in a specific Confluent Cloud environment.

    For more details, see Resource scopes.

• Operation group: A system-defined set of operations that can be protected with IP filtering. Operation groups fall into Management, Monitoring, and Data categories. For more details, see Operation groups.

• Public network connections: IP filters apply only to requests from public networks and have no effect on requests over customer-configured private network connections.

Steps to implement IP filtering

Before implementing IP filtering, verify you want to limit public access to your resources.

To implement IP filtering, you must define the IP groups that represent known and trusted public networks and define IP filters to limit access to only the defined IP groups.

1. Create IP groups for each trusted network location, naming each IP group to match the trusted network location.

2. Create IP filters that associate IP groups with the resource scope and operation groups. To block all public network access, create an IP filter that allows No Public Networks. Name each filter to describe the group and access.

3. Verify that your IP filters work as expected:

   1. Attempt to access your Confluent Cloud resources from an IP address not included in your IP filters. Verify that the attempt is denied.

   2. Attempt to access your Confluent Cloud resources from an IP address included in your IP filters. Verify that the attempt is allowed.

Resource scopes

Resource scopes define the level at which IP filtering rules apply within your Confluent Cloud organization. You can create IP filters that apply to the entire organization with an organization scope or a specific environment with the environment scope.

Multiple IP filters at the same organization or environment scope level are additive, meaning they expand the set of allowed IP addresses. For example, if one filter allows access from IP group A and another filter at the same scope allows access from IP group B, requests from either IP group A or B pass through.

When IP filters exist at organization and environment scope:

• A request must satisfy all applicable organization and environment-level filters to be allowed.

• Organization-level filters are the broadest policy that cover all environments unless further restricted.

• Environment-level filters can only add additional restrictions, not remove organization-level restrictions.

For example, if an organization has IP filters that allow access only from the production datacenters, an environment-level filter can’t override this to allow access from development networks. However, the environment-level filter could further restrict access to only a specific production datacenter.

Note

When viewing IP filters for an environment, both environment-specific filters and organization-wide filters that affect that environment appear to provide a complete picture of access controls.

You can specify the resource scope during the creation of an IP filter through any of these interfaces:

• Confluent Cloud Console: When you create an IP filter from the Accounts & access page, the IP filter is scoped to the entire organization. If you create the IP filter from the Environment > Network Management > For public networks page, the IP filter is scoped to that environment.

• Confluent CLI: Use the --environment flag to specify the environment for the IP filter. If you do not specify the --environment flag, the IP filter applies to the entire organization.

• Confluent Cloud APIs: Use the resource_scope field to specify the resource scope. If you do not specify this parameter, the IP filter applies to the entire organization.

  The Confluent Resource Name (CRN) identifies the scope of an IP filter, which can be your entire organization or a specific environment.

  • An organization-scoped IP filter might have a resource_scope value of:

    crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a
    

  • An environment-scoped IP filter might have a resource_scope value of:

    crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a/environment=env-abc123
    

  When you create an IP filter, you can specify a resource_scope value to control the scope of the IP filter. The following rules apply:

  • When resource_scope is empty, which is the default, the IP filter applies to your entire organization.

  • When a resource scope is specified, it’s immutable and can’t be changed after the IP filter is created.

Operation groups

Operation groups are collections of operations that can be controlled collectively by an IP filter. You must select one or more operation groups to control which operations each IP filter applies to.

You can specify operation groups when creating an IP filter through any of these interfaces:

• Confluent Cloud Console: Select operation groups in the Operation groups section when adding a new IP filter.

• Confluent CLI: Use the --operations flag to specify operation groups when creating an IP filter.

• Confluent Cloud APIs: Include operation groups using the operation_groups field in your API request.

  Note

  To be able to specify operation groups in an API request, you must include the resource_group field with a value of multiple. This indicates that operation groups are defined using the operation_groups field.

Identifiers

The following table lists the names and identifiers for the operation groups.

Operation groups

Category	Operation group	Identifier
Management	Resource management	MANAGEMENT
Management	Schema management	SCHEMA
Management	Catalog management	CATALOG
Management	Kafka Discovery	KAFKA_DISCOVERY
Management	Kafka Management	KAFKA_MANAGEMENT
Monitoring	Logging	LOGS
Monitoring	Metrics	METRICS
Data	Flink	FLINK
Data	Kafka data	KAFKA_DATA
Data	ksqlDB	KSQL

Note

Confluent Cloud does not support IP filtering for the catalog management, logging, and metrics operation groups.

Operations

The following sections list the operations for each operation group.

Resource management

The Resource management operation group covers operations to manage Confluent Cloud resources and configurations including the following:

• Create, update, and delete organizations and environments

• Manage users, service accounts, and API keys

• Configure identity providers, identity pools, and SSO settings

• Create and manage Kafka clusters, Confluent Schema Registry clusters, ksqlDB clusters, and Confluent Cloud for Apache Flink compute pools

• Configure networking resources such as VPC peering, private links, and transit gateway attachments

• Manage connectors and connector plugins

• Configure billing, quotas, and service limits

• Set up notifications and integrations

• Manage stream sharing and data catalog resources

Schema management

The Schema management operation group covers operations to manage schemas and encryption keys in Confluent Schema Registry including the following:

• Read, write, and delete schema subjects

• Read and write schema compatibility settings

• Register, deregister, and update key encryption keys (KEK)

Kafka Discovery

The Kafka Discovery operation group covers operations to view Kafka cluster resources and their configurations including the following:

• Describe topics

• Describe and read consumer groups

• Describe transactional IDs

Note

The Kafka Discovery operation group is typically required when you allow access to either the Kafka Management or Kafka data operation groups.

Kafka Management

The Kafka Management operation group covers operations to configure and manage Kafka cluster resources including the following:

• Create, alter, delete, and describe topics

• Configure topic settings

• Alter and delete consumer groups

• Configure consumer group settings

• Manage cluster configurations

• Perform cluster actions

• Manage cluster links

• Create and describe delegation tokens for users

Flink

The Flink operation group covers operations to create and manage Confluent Cloud for Apache Flink SQL statements, workspaces, and AI-powered resources including the following:

• Create, alter, delete, and describe Flink statements

• Create, alter, delete, and describe materialized tables

• Create, alter, delete, and describe workspaces

• Manage AI agents, functions, models, and tools

• Write data to compute pools

Kafka data

The Kafka data operation group covers operations to produce and consume data to and from Kafka topics including the following:

• Read data from topics

• Write data to topics

• Perform idempotent writes to the cluster

• Perform two-phase commits for transactional IDs

• Write to transactional IDs

ksqlDB

The ksqlDB operation group covers operations to use ksqlDB clusters to process streaming data including the following:

• Contribute to ksqlDB clusters (run queries and manage streams and tables)

Limitations

IP filtering currently has the following limitations:

• When an IP filter is applied to the resource management operation group, creating a connector by executing a KSQL statement fails.

• Only IPv4 CIDR blocks are supported.

• IP filters including the management operation group are not supported at the environment scope.

• Confluent Cloud does not support IP filtering for the catalog management, logging, and metrics operation groups.

• You can create at most 25 IP groups and 25 IP filters in an organization. For the full set of quotas, see IP group limits and IP filter limits.

• The resource scope of an IP filter can’t be changed after the IP filter is created.

Related content

• Manage IP Filters

• Manage IP Groups

• Best Practices for IP Filtering

• Confluent CLI Reference: confluent iam ip-group

• Confluent CLI Reference: confluent iam ip-filter

• Confluent API Reference: IP Groups

• Confluent API Reference: IP Filters

• Terraform confluent_ip_filter Resource

• Terraform confluent_ip_group Resource