<a id="ip-filtering"></a>

<a id="ip-filtering-overview"></a>

# 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](../../../_glossary.md#term-CIDR-block), 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](../../../_glossary.md#term-CIDR-block) 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](#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](#ip-filter-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](../../../networking/overview.md#cloud-networking-support-private).

## 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](manage-ip-groups.md#create-ip-group) for each trusted network location,
   naming each IP group to match the trusted network location.
2. [Create IP filters](manage-ip-filters.md#create-ip-filter) 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.

<a id="resource-scopes"></a>

## 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)](../hierarchy/confluent-resource-names.md#confluent-resource-names)
  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:
    ```shell
    crn://confluent.cloud/organization=9bb441c4-edef-46ac-8a41-c49e44a3fd9a
    ```
  * An environment-scoped IP filter might have a `resource_scope` value of:
    ```shell
    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.

<a id="ip-filter-operation-groups"></a>

## 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.

<a id="operation-group-identifiers"></a>

### 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.

<a id="operation-group-permissions"></a>

### Operations

The following sections list the operations for each operation group.

<a id="resource-management-api-operations"></a>

#### 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

<a id="schema-management-api-operations"></a>

#### 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)

<a id="kafka-discovery-operation-group"></a>

#### 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.

<a id="kafka-management-operation-group"></a>

#### 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

<a id="flink-operation-group-api-operations"></a>

#### 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

<a id="kafka-data-operation-group"></a>

#### 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

<a id="ksql-operation-group"></a>

#### 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](manage-ip-groups.md#ip-group-limits) and
  [IP filter limits](manage-ip-filters.md#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-filters.md#manage-ip-filters)
* [Manage IP Groups](manage-ip-groups.md#manage-ip-groups)
* [Best Practices for IP Filtering](best-practices.md#ip-filtering-best-practices)
* [Confluent CLI Reference: confluent iam ip-group](https://docs.confluent.io/confluent-cli/current/command-reference/iam/ip-group/index.html)
* [Confluent CLI Reference: confluent iam ip-filter](https://docs.confluent.io/confluent-cli/current/command-reference/iam/ip-filter/index.html)
* [Confluent API Reference: IP Groups](/cloud/current/api.html#tag/IP-Groups-(iamv2))
* [Confluent API Reference: IP Filters](/cloud/current/api.html#tag/IP-Filters-(iamv2))
* [Terraform confluent_ip_filter Resource](https://registry.terraform.io/providers/confluentinc/confluent/latest/docs/resources/confluent_ip_filter)
* [Terraform confluent_ip_group Resource](https://registry.terraform.io/providers/confluentinc/confluent/latest/docs/resources/confluent_ip_group)