Confluent package v1.0.0

A Confluent Cloud API key held in the client's own secret manager. Authentication is HTTP Basic over the key pair: the stored material must be the complete Authorization header value — the scheme 'Basic', one separating space, then the Base64 encoding of 'API_KEY_ID:API_SECRET' — and the injector injects the stored value verbatim. Keys are issued in the Confluent Cloud Console or CLI, and each key is owned by a principal (user account or service account) whose permissions the key inherits; permissions live on the principal, not on the key.

Key permissions: a Cloud API key scoped for cloud resource management covers the org/v2, cmk/v2 and iam/v2 management endpoints, while the kafka/v3 topic operations on a cluster's own endpoint require a resource-specific API key scoped to that Kafka cluster — store the key matching each capability's surface (per-capability secret_ref_id overrides exist for this), and do not pretend one reference covers both. This pack names that second reference 'secret-ref-confluent-kafka-api-key': its stored material has the identical wire format — 'Basic', one space, then Base64 of 'API_KEY_ID:API_SECRET' — but the underlying key is a resource-specific API key created for one Kafka cluster (the fetched api-keys page documents that Kafka-cluster-scoped keys specify the Environment and the cluster at creation), and its lifecycle matches the Cloud key's: no documented expiry, valid until deleted in the Console/CLI or until its owning principal is deleted, rotation by issue-replace-delete.

Least privilege: Confluent strongly recommends service accounts over user accounts for production; use a dedicated service account per integration with only the roles or ACLs these capabilities need, and note that key permissions track the principal's roles as they change.

Expiry and revocation: the reviewed documentation describes no key expiry — a key remains valid until it is deleted in the Console/CLI or until its owning principal is deleted (which automatically deletes all its keys); disabling the ability to create new keys does not invalidate already-issued keys, so revocation means deleting each issued key, and rotation means issuing a replacement, updating this reference, then deleting the old key.

Rotation ownership sits with an external deployment process; the executor performs no key lifecycle itself.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

Two endpoint hosts appear in this pack, and both are reserved non-production placeholders (RFC 2606 reserved TLD): 'confluent-cloud.invalid' stands in for the Confluent Cloud management API host (the documented host is api.confluent.cloud, serving the org/v2, cmk/v2 and iam/v2 API groups), and 'confluent-cluster.invalid' stands in for a Kafka cluster's own per-cluster Kafka REST endpoint host (documented shape: a pkc-... host specific to each cluster), which serves the kafka/v3 topic operations.

Substitute both before enabling — in every endpoint, in both resource locators and in every egress allowlist entry; the allowlist matches exactly, and substitution is a required deployment step. ENV_ID, CLUSTER_ID, TOPIC_NAME and KEY_ID are placeholders the deployment binds to concrete resources before enabling. Key scopes: management API calls take a Cloud API key scoped for cloud resource management, while the topic operations on a cluster's own endpoint take a resource-specific API key scoped to that Kafka cluster — the deployment must store the key whose scope matches the capability (per-capability secret_ref overrides exist for exactly this), or operate two references; one key does not honestly cover both surfaces.

Excluded operations: API key creation (POST /iam/v2/api-keys — minting new credentials stays with the Console or CLI under direct human control; this pack registers only revocation), user and service-account management and invitations, RBAC role bindings and ACL management (granting access to principals is access-sharing and deserves its own review), connector management (connectors move data between systems — send/share semantics needing their own review), Schema Registry writes (subject deletion and compatibility changes), ksqlDB and Flink statement execution, produce/consume data-plane operations (Kafka REST produce is message sending), cluster networking (PrivateLink, peering, transit gateway) and Marketplace/billing operations.

The Confluent API reference's per-endpoint pages are client-side rendered; the routes registered here follow the documented API-group shapes (org/v2, cmk/v2, iam/v2, kafka/v3) and were verified on 2026-09-21 against the retrieved Confluent OpenAPI specification (see the review record), not only the overview and authentication pages. Verified cluster contract: GET and DELETE require the environment query parameter. PATCH takes no query parameters and requires spec.environment in the request body, as established by the retrieved OpenAPI specification; see the update capability.