# FedRAMP Security Best Practices for Confluent Cloud for Government This guide provides best practices for meeting the required FedRAMP FRR-RSC controls within Confluent Cloud for Government. For more details about Confluent Cloud for Government security controls, see the [Building Trust with Confluent Cloud](https://assets.confluent.io/m/67f93edfe1a9f524/original/20200805-WP-Confluent_Cloud_Security_Controls.pdf) and [Manage security on Confluent Cloud](/cloud/current/security/overview.html). ## Secure defaults and authentication protections **Applicable FRR-RSC Controls:** FRR-RSC-04 Confluent Cloud for Government enforces strict security defaults at the platform level through your identity provider with Confluent Cloud for Government. These single sign-on (SSO) settings are applied automatically upon provisioning and cannot be weakened by tenants. By using [SSO settings](/cloud/current/security/authenticate/user-identities/user-idps/sso/overview.html), you can easily enforce security controls, such as multi-factor authentication (MFA). To enable a strong security posture, ensure all users login only via SSO with MFA enabled on the identity provider. ## Manage access for administrative accounts **Applicable FRR-RSC Controls:** FRR-RSC-01, FRR-RSC-02, FRR-RSC-03 Confluent Cloud for Government uses a hierarchical [role-based access control (RBAC)](/cloud/current/security/access-control/rbac/overview.html) model. ### Provision an administrator The OrganizationAdmin role is the top-level authority, capable of managing the entire tenant, including billing, SSO, and user lifecycle. The OrganizationAdmin role is the only role with the following capabilities: * Identity Management: Configure SSO, invite users, and create Service Accounts. * Billing & Contracts: View invoices, update payment methods, and manage contract details. * Global Security: Enforce MFA policies via SSO and view organization-wide audit logs. All users in an organization must be invited via SSO. See [Add an SSO user](/cloud/current/access-management/identity/user-accounts.html#add-an-sso-user). Once a user has been added to the organization, you can grant the appropriate role to a user via the CLI or API: ### CLI To grant a user top-level administrative access, use the `confluent iam rbac role-binding create` command. ```bash confluent iam rbac role-binding create \ --principal User:alice@example.com \ --role OrganizationAdmin ``` Additional flags are available for [confluent iam rbac role-binding create](https://docs.confluent.io/confluent-cli/current/command-reference/iam/rbac/role-binding/confluent_iam_rbac_role-binding_create.html). ### API Use the IAM API to programmatically assign roles: ```bash curl --request POST \ --url https://api.confluentgov.com/iam/v2/role-bindings \ --header 'Authorization: Basic REPLACE_BASIC_AUTH' \ --header 'content-type: application/json' \ --data '{ \ "principal":"User:", \ "role_name":"", \ "crn_pattern":"crn://confluent.cloud/organization=/environment=/cloud-cluster=" \ }' ``` For more, see the [Create a Role Binding](/cloud/current/api.html#tag/Role-Bindings-(iamv2)/operation/createIamV2RoleBinding). #### WARNING When an administrator leaves an organization or changes roles, immediately revoke their access or scope it according to their new role. You can decommission a top-level admin account by removing the role binding or deleting the user identity entirely using the CLI or API. You can use [confluent iam rbac role-binding delete CLI command](https://docs.confluent.io/confluent-cli/current/command-reference/iam/rbac/role-binding/confluent_iam_rbac_role-binding_delete.html) or [Delete a Role Binding via the API](/cloud/current/api.html#tag/Role-Bindings-(iamv2)/operation/deleteIamV2RoleBinding). For more, see the [CLI Command Reference](/cloud/current/command-reference/overview.html) and [API Reference](/cloud/current/api/index.html). ### Grant least privilege for role To adhere to the principle of least privilege, avoid granting OrganizationAdmin for day-to-day operations. Limit access to only the resources required for the user’s role. To start, [add an SSO user](/cloud/current/access-management/identity/user-accounts.html#add-an-sso-user). For admin roles, scope access to specific resources instead of granting OrganizationAdmin: * EnvironmentAdmin: Full control over a specific environment (e.g., Production vs. Staging). Can create/delete clusters but cannot modify SSO or Billing. * CloudClusterAdmin: Full control over a specific Kafka cluster. Can manage Topics, access control lists (ACLs), and API Keys but cannot delete the cluster itself. Other roles include ResourceKeyAdmin, MetricsViewer, AccountAdmin, Operator, NetworkAdmin, and ResourceOwner. To see the permissions for these roles, see [Predefined RBAC Roles](/cloud/current/security/access-control/rbac/predefined-rbac-roles.html) model. ## Audit and compare security settings **Applicable FRR-RSC Controls:** FRR-RSC-05, FRR-RSC-06, FRR-RSC-07 You can verify your current security posture against your requirements using the [CLI commands](/cloud/current/command-reference/overview.html) and [API endpoints](/cloud/current/api/index.html). ### Audit users and roles You can get a list of granted roles or permissions using the CLI or API, which support machine-readable output (`json` or `yaml`) for easy integration with compliance tools. ### CLI List all users and their status: ```bash confluent iam user list --output json ``` The output the users and their authentication type. For example: ```json [ { "api_version": "iam/v2", "kind": "User", "id": "u-123456", "email": "admin@agency.gov", "auth_type": "SSO" } ] ``` ### API Use the IAM API to see a list of all users: ```bash curl --request GET \ --url https://api.confluentgov.com/iam/v2/users \ --header 'Authorization: Basic ' ``` The output is a list of users and their authentication type. For example: ```json { "api_version": "iam/v2", "kind": "UserList", "metadata": { "first": "https://api.confluentgov.com/iam/v2/users", "last": "https://api.confluentgov.com/iam/v2/users?page_token=bcAOehAY8F16YD84Z1wT", "prev": "https://api.confluentgov.com/iam/v2/users?page_token=YIXRY97wWYmwzrax4dld", "next": "https://api.confluentgov.com/iam/v2/users?page_token=UvmDWOB1iwfAIBPj6EYb", "total_size": 123 }, "data": [ { "api_version": "iam/v2", "kind": "User", "id": "dlz-f3a90de", "metadata": { "self": "https://api.confluentgov.com/iam/v2/users/", "resource_name": "crn://confluentgov.com/user=", "created_at": "2006-01-02T15:04:05-07:00", "updated_at": "2006-01-02T15:04:05-07:00", "deleted_at": "2006-01-02T15:04:05-07:00" }, "email": "", "full_name": "", "auth_type": "AUTH_TYPE_SSO" } ] } ``` For more, see the [List of Users](/cloud/current/api.html#tag/Users-(iamv2)/operation/listIamV2Users). ### Audit privileged access You can list every principal (User or Service Account) that holds the OrganizationAdmin role using the CLI or API. ### CLI To list every principal (User or Service Account) that holds the OrganizationAdmin role, use: ```bash confluent iam rbac role-binding list \ --role OrganizationAdmin \ --output json ``` ### API To retrieve all principals with the OrganizationAdmin role using the API: ```bash curl --request GET \ --url "https://api.confluentgov.com/iam/v2/role-bindings?role_name=OrganizationAdmin" \ --header 'Authorization: Basic ' ``` The API response includes all principals (users and service accounts) that have been granted the OrganizationAdmin role. For example: ```json { "api_version": "iam/v2", "kind": "RoleBindingList", "metadata": { "first": "https://api.confluent.cloud/iam/v2/role-bindings", "last": "https://api.confluent.cloud/iam/v2/role-bindings?page_token=bcAOehAY8F16YD84Z1wT", "prev": "https://api.confluent.cloud/iam/v2/role-bindings?page_token=YIXRY97wWYmwzrax4dld", "next": "https://api.confluent.cloud/iam/v2/role-bindings?page_token=UvmDWOB1iwfAIBPj6EYb", "total_size": 123 }, "data": [ { "api_version": "iam/v2", "kind": "RoleBinding", "id": "", "metadata": { "self": "https://api.confluent.cloud/iam/v2/role-bindings/", "resource_name": "crn://confluent.cloud/organization=/role-binding=", "created_at": "2006-01-02T15:04:05-07:00", "updated_at": "2006-01-02T15:04:05-07:00", "deleted_at": "2006-01-02T15:04:05-07:00" }, "principal": "User:", "role_name": "OrganizationAdmin", "crn_pattern": "crn://confluent.cloud/organization=/environment=/cloud-cluster=" } ] } ``` ### Audit access control lists If you use ACLs alongside RBAC for fine-grained control, you can export them to audit who has access to specific topics. ### CLI To list all ACLs for a Kafka cluster using the CLI: ```bash confluent kafka acl list --cluster --output yaml ``` ### API To retrieve all ACLs for a Kafka cluster using the API: ```bash curl --request GET \ --url "https://api.confluentgov.com/kafka/v3/clusters//acls" \ --header 'Authorization: Basic ' ``` This is the expected API response: ```json { "kind": "KafkaAclList", "metadata": { "self": "https://api.confluentgov.com/kafka/v3/clusters//acls", "next": null }, "data": [ { "kind": "KafkaAcl", "metadata": { "self": "https://api.confluentgov.com/kafka/v3/clusters//acls?resource_type=CLUSTER&resource_name=&pattern_type=LITERAL&principal=User%3Ausername&host=*&operation=READ&permission=ALLOW" }, "cluster_id": "", "resource_type": "CLUSTER", "resource_name": "", "pattern_type": "LITERAL", "principal": "User:", "host": "*", "operation": "READ", "permission": "ALLOW" } ] } ``` ## Monitor the audit log cluster **Applicable FRR-RSC Controls:** FRR-RSC-01 (Note), FRR-RSC-07 Confluent Cloud for Government provides a dedicated Audit Log Cluster for every organization. This is a separate, read-only Kafka cluster that contains an immutable log of all security events. For more, see [Access and Consume Audit Logs](/cloud/current/monitoring/audit-logging/configure.html). ### Integrate audit logs with your SIEM Confluent Cloud for Government generates detailed audit logs for critical events, including authentication, RBAC changes, and resource creation. These logs are retained in the Confluent Cloud for Government audit cluster for only seven days. To meet FedRAMP retention and monitoring requirements, you must actively consume these logs and ship them to your organization’s Security Information and Event Management (SIEM) or cold storage. 1. Identify the Audit Cluster. Every organization has a dedicated, read-only Kafka cluster for audit logs. ```bash confluent audit-log describe ``` This command returns the cluster ID (e.g., `lkc-audit1`) and environment ID. For example: ```bash +-----------------+----------------------------+ | Cluster | lkc-yokxv6 | | Environment | env-abc123 | | Service Account | sa-ymnkzp | | Topic Name | confluent-audit-log-events | +-----------------+----------------------------+ ``` 2. Configure Ingestion: Set up a dedicated Service Account and API Key to consume from the `confluent-audit-log-events` topic. ```bash confluent api-key create --resource --service-account ``` This command returns the API key and secret. For example: ```bash +---------+------------------------------------------------------------------+ | API Key | ABC123xyz | | Secret | cfltABC123xyzABC123xyzABC123xyzABC123xyzABC123xyzABC123xyzABCxyz | +---------+------------------------------------------------------------------+ ``` 3. Use a Kafka Sink Connector (e.g., Splunk, Datadog, S3, or Elasticsearch) to automatically stream these logs from the Confluent audit cluster to your centralized logging platform for long-term retention and threat analysis. ### Auditable events The audit log captures the following critical security events: * Authentication: Login successes/failures, SSO events. * Authorization: RBAC and ACL checks (Allowed/Denied). * Management: Creation/Deletion of API Keys, modification of User accounts, and changes to Network settings (e.g., Private Link). ## Security updates and release notes **Applicable FRR-RSC Controls:** FRR-RSC-10 Confluent Cloud for Government follows a continuous delivery model. Security updates are documented in the [Confluent Cloud for Government Release Notes](../support/release-notes.md) and [Confluent Cloud Release Notes](/cloud/current/release-notes/index.html). Review these release notes at a regular interval, such as monthly or quarterly, for changes to default behavior, RBAC roles, and authentication flows.