confluent v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-confluent-cloud-api-key

Custody

customer_vault

Injection

header (Authorization)

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. Scope honesty: 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 fetched 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.

• confluent-environment (api, internal): https://confluent-cloud.invalid/org/v2/environments/ENV_ID
• confluent-kafka-cluster (api, internal): https://confluent-cluster.invalid/kafka/v3/clusters/CLUSTER_ID

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. Two key scopes, honestly: 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. Documented exclusions — this pack does not register: 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; routes registered here follow the documented API-group shapes (org/v2, cmk/v2, iam/v2, kafka/v3) described in the fetched API overview and authentication pages, and each route should be re-verified against the live reference before enabling — one reason this pack stays in draft state. Specific unverified item: the GET and DELETE cluster shapes place the environment as an '?environment=' query parameter, but the per-endpoint cmk PATCH page was client-rendered and unreachable this session, so the update capability's environment placement (query string versus request specification) is unverified — see that capability's description.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://docs.confluent.io/cloud/current/api.html (retrieved 2026-09-21)
• https://docs.confluent.io/cloud/current/access-management/authenticate/api-keys/api-keys.html (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.