# Security Controls in Confluent Cloud for Apache Flink Confluent Cloud for Apache Flink® protects data and isolates tenants through three layers of security controls: network controls that govern access between public and private endpoints, compute isolation that separates customer workloads in the data plane, and runtime sandboxing for user-defined functions (UDFs) and custom connector plugins. The following sections describe each control: - Network security for public and private endpoints - Compute isolation and data plane security - User-defined functions (UDFs) and custom connector plugin security ## Network security controls Flink can execute statements against multiple cluster resources running in the same or different Confluent Cloud environments. Access patterns depend on the Flink endpoint type that you deploy. ### Public endpoints Flink statements that you issue from public endpoints in a supported cloud service provider region can read and write Confluent Cloud cluster resources running on public endpoints inside the same and other Confluent Cloud environments within the same Confluent Cloud organization. Statements running on public endpoints cannot access Confluent Cloud cluster resources running on private endpoints. ### Private endpoints Flink statements that you issue from private endpoints can read and write Confluent Cloud cluster resources running on private endpoints inside the same and other Confluent Cloud environments within the same organization. All Confluent Cloud environments that Flink accesses using private networking must be in the same cloud region. Flink statements that you issue on private endpoints can execute read, but not write, statements against Confluent Cloud cluster resources running on public endpoints with the same or different Confluent Cloud organization. This policy addresses data exfiltration risks. For more information about private networking, see [Private Networking with Confluent Cloud for Apache Flink](flink-private-networking.md#flink-sql-private-networking). ## Compute isolation and security controls Flink implements a multi-layered security architecture with strict isolation between tenants at both the control plane and data plane levels. ### Control plane architecture The Flink control plane is fully multi-tenant and runs in-region across three Availability Zones (AZs). It manages resources, metadata, and operations for all tenants. ### Data plane architecture The Flink data plane currently spans a single [compute pool](compute-pools.md#flink-sql-compute-pools). Although Flink shares the underlying compute nodes, the actual Flink processes run as dedicated, single-tenant pods that process data only for that specific pool. The data plane provides strict resource isolation and resource usage controls with cgroups, dedicated pods per compute pool, and single-tenant processing per pool. ### Component isolation #### Compute pools Each compute pool can span multiple compute nodes that contain multiple task managers, all of which a single job manager manages. #### Job managers Job managers oversee resource management across applications, scoped by compute pool. Although they target multi-tenant deployment, they currently run single-tenant. #### Task managers Task managers execute the actual data processing tasks. Task managers operate in single-tenant capacity. #### RocksDB state storage Each task manager uses a dedicated, isolated Kubernetes volume for RocksDB persistence, enforcing data segregation on shared compute nodes. Flink uploads state to object storage for resiliency as part of the 60-second checkpointing interval. #### Object storage for state Flink stores checkpointing state in encrypted object storage and authenticates by using regional IAM roles. Only task managers have access to object store state. Users can’t initiate checkpoints or access object storage through arbitrary object store paths. For more information about compute pools, see [Compute Pools in Confluent Cloud for Apache Flink](compute-pools.md#flink-sql-compute-pools). ## User-defined functions and custom connector plugin security [UDFs](user-defined-functions.md#flink-sql-udfs) and [custom connector plugins](../../connectors/bring-your-connector/custom-connector-manage.md#cc-bring-your-connector-manage) execute in a secure, multi-zone environment with isolated cloud accounts and Kafka pods. Each zone applies strict security measures that align with Confluent security practices. ### Isolated execution environment UDFs and plugins execute in dedicated cloud accounts under least privilege access with zero-trust relationships to Confluent Cloud production environments. Execution occurs in isolated, untrusted virtual machines with seccomp-jailing for system call filtering and strict network policies. ### Security monitoring Workload protection agents monitor for security threats, and Confluent enables full audit logging. Confluent stores UDFs and plugins with unique pod mappings, and pre-signed, time-limited URLs prevent unauthorized access. For more information about UDFs, see [User-defined Functions in Confluent Cloud for Apache Flink](user-defined-functions.md#flink-sql-udfs). ## Related content - [Private Networking with Confluent Cloud for Apache Flink](flink-private-networking.md#flink-sql-private-networking) - [Compute Pools in Confluent Cloud for Apache Flink](compute-pools.md#flink-sql-compute-pools) - [User-defined Functions in Confluent Cloud for Apache Flink](user-defined-functions.md#flink-sql-udfs) #### NOTE This website includes content developed at the [Apache Software Foundation](https://www.apache.org/) under the terms of the [Apache License v2](https://www.apache.org/licenses/LICENSE-2.0.html).