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 and Manage security on Confluent Cloud.

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, 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) 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. 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.

confluent iam rbac role-binding create \
 --principal User:alice@example.com \
 --role OrganizationAdmin

Additional flags are available for confluent iam rbac role-binding create.

API

Use the IAM API to programmatically assign roles:

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:<UUID>", \
      "role_name":"<role_name>", \
      "crn_pattern":"crn://confluent.cloud/organization=<organization_id>/environment=<environment_id>/cloud-cluster=<cluster_id>" \
      }'

For more, see the Create a Role Binding.

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 or Delete a Role Binding via the API.

For more, see the CLI Command Reference and API Reference.

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.

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 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 and API endpoints.

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:

confluent iam user list --output json

The output the users and their authentication type. For example:

[
 {
 "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:

curl --request GET \
   --url https://api.confluentgov.com/iam/v2/users \
   --header 'Authorization: Basic <authentication_credentials>'

The output is a list of users and their authentication type. For example:

{
   "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/<user_id>",
            "resource_name": "crn://confluentgov.com/user=<user_id>",
            "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": "<user_email>",
         "full_name": "<user_name>",
         "auth_type": "AUTH_TYPE_SSO"
         }
      ]
   }

For more, see the List of Users.

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:

confluent iam rbac role-binding list \
  --role OrganizationAdmin \
  --output json

API

To retrieve all principals with the OrganizationAdmin role using the API:

curl --request GET \
  --url "https://api.confluentgov.com/iam/v2/role-bindings?role_name=OrganizationAdmin" \
  --header 'Authorization: Basic <authentication_credentials>'

The API response includes all principals (users and service accounts) that have been granted the OrganizationAdmin role. For example:

{
   "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": "<cluster_id>",
         "metadata": {
            "self": "https://api.confluent.cloud/iam/v2/role-bindings/<rb_id>",
            "resource_name": "crn://confluent.cloud/organization=<organization_id>/role-binding=<rb_id>",
            "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:<user_id>",
         "role_name": "OrganizationAdmin",
         "crn_pattern": "crn://confluent.cloud/organization=<organization_id>/environment=<environment_id>/cloud-cluster=<cluster_id>"
      }
   ]
}

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:

confluent kafka acl list --cluster <cluster-id> --output yaml

API

To retrieve all ACLs for a Kafka cluster using the API:

curl --request GET \
  --url "https://api.confluentgov.com/kafka/v3/clusters/<cluster-id>/acls" \
  --header 'Authorization: Basic <authentication_credentials>'

This is the expected API response:

{
  "kind": "KafkaAclList",
  "metadata": {
    "self": "https://api.confluentgov.com/kafka/v3/clusters/<cluster-id>/acls",
    "next": null
  },
  "data": [
    {
      "kind": "KafkaAcl",
      "metadata": {
        "self": "https://api.confluentgov.com/kafka/v3/clusters/<cluster-id>/acls?resource_type=CLUSTER&resource_name=<cluster_name>&pattern_type=LITERAL&principal=User%3Ausername&host=*&operation=READ&permission=ALLOW"
      },
      "cluster_id": "<cluster-id>",
      "resource_type": "CLUSTER",
      "resource_name": "<cluster_name>",
      "pattern_type": "LITERAL",
      "principal": "User:<user_name>",
      "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.

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.

   confluent audit-log describe
   

   This command returns the cluster ID (e.g., lkc-audit1) and environment ID. For example:

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

   confluent api-key create --resource <audit-cluster-id> --service-account <sa-id>
   

   This command returns the API key and secret. For example:

   +---------+------------------------------------------------------------------+
   | 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 and Confluent Cloud Release Notes.

Review these release notes at a regular interval, such as monthly or quarterly, for changes to default behavior, RBAC roles, and authentication flows.