chore(platform): drop the unused GCP service account key #682

Merged

binjovi-bot merged 1 commit from chore/drop-unused-gcp-key into trunk 2026-09-14 15:35:37 +00:00

Conversation 0 Commits 1 Files changed 1 -47

sean commented 2026-09-14 15:35:05 +00:00

Owner

Copy link

XPlatform mints a key for seanfarm-platform-iam and writes it to Secret
clouddns-service-account in the openbao namespace. Nothing reads it.

The stated consumer does not exist

The comment claims OpenBao's GCP secrets engine uses the key so per-tenant
external-dns rolesets can mint ephemeral SAs. Verified against the cluster:

• zero openbaogcprolesets
• zero openbaogcpsecretsbackends
• this composition never creates the mount the comment describes
• the rolesets lived in apis/stack, deleted along with the tenants

It is not the credential cert-manager uses

There are two Secrets with the same name, and the live one is the other:

	namespace	keys	source
in use	cert-manager	credentials.json	SOPS via dns-admin-credentials, generated by run-ensure-dns-iam.sh
this one	openbao	private_key, attribute.private_key	Crossplane connection secret

No workload, CR or manifest references the openbao one.

So this is a live GCP service account private key sitting in the cluster,
unused and unrotated — and the only composed resource without
deletionPolicy: Retain. Removing it from the composition deletes the key in
GCP, which is the point. The service account itself is unaffected;
run-ensure-platform-iam.sh owns that, not Crossplane.

First step of retiring Crossplane

Ten APIs are already gone and the README records where each concern went.
XPlatform is the last composition. After this it composes ten resources, all
OpenBao consumer CRs carrying deletionPolicy: Retain — which is what makes the
remaining steps safe.

All platform-seanfarm guards pass.

https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA

`XPlatform` mints a key for `seanfarm-platform-iam` and writes it to Secret `clouddns-service-account` in the `openbao` namespace. **Nothing reads it.** ### The stated consumer does not exist The comment claims OpenBao's GCP secrets engine uses the key so per-tenant external-dns rolesets can mint ephemeral SAs. Verified against the cluster: - **zero** `openbaogcprolesets` - **zero** `openbaogcpsecretsbackends` - this composition never creates the mount the comment describes - the rolesets lived in `apis/stack`, deleted along with the tenants ### It is not the credential cert-manager uses There are two Secrets with the same name, and the live one is the other: | | namespace | keys | source | | --- | --- | --- | --- | | **in use** | `cert-manager` | `credentials.json` | SOPS via `dns-admin-credentials`, generated by `run-ensure-dns-iam.sh` | | this one | `openbao` | `private_key`, `attribute.private_key` | Crossplane connection secret | No workload, CR or manifest references the `openbao` one. So this is a **live GCP service account private key sitting in the cluster, unused and unrotated** — and the only composed resource without `deletionPolicy: Retain`. Removing it from the composition deletes the key in GCP, which is the point. The service account itself is unaffected; `run-ensure-platform-iam.sh` owns that, not Crossplane. ### First step of retiring Crossplane Ten APIs are already gone and the README records where each concern went. `XPlatform` is the last composition. After this it composes ten resources, all OpenBao consumer CRs carrying `deletionPolicy: Retain` — which is what makes the remaining steps safe. All platform-seanfarm guards pass. https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA

sean added 1 commit 2026-09-14 15:35:06 +00:00

chore(platform): drop the unused GCP service account key ... 0a86f5cd86

XPlatform minted a key for seanfarm-platform-iam and wrote it to Secret
clouddns-service-account in the openbao namespace. Nothing reads it.

The comment said OpenBao's GCP secrets engine used the key so per-tenant
external-dns rolesets could mint ephemeral SAs. That consumer does not
exist. The cluster has zero openbaogcprolesets and zero
openbaogcpsecretsbackends, this composition never created the mount the
comment describes, and the rolesets lived in apis/stack, which was
deleted with the tenants.

The DNS-01 credential cert-manager actually uses is a different Secret
with the same name: clouddns-service-account in namespace cert-manager,
key credentials.json, delivered from SOPS through dns-admin-credentials
and generated by scripts/run-ensure-dns-iam.sh. The Crossplane one is in
namespace openbao with keys private_key and attribute.private_key, and no
workload, CR or manifest references it.

So this is a live GCP service account private key sitting in the cluster,
unused and unrotated, and the only composed resource without
deletionPolicy: Retain. Removing it from the composition deletes the key
in GCP, which is the point. The service account itself is unaffected;
run-ensure-platform-iam.sh owns that, not Crossplane.

This is the first step of retiring Crossplane. Ten APIs are already gone;
XPlatform is the last composition, and after this it composes ten
resources, all of them OpenBao consumer CRs that carry
deletionPolicy: Retain.

All platform-seanfarm guards pass.

Claude-Session: https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA

binjovi-bot merged commit 0a86f5cd86 into trunk 2026-09-14 15:35:37 +00:00

binjovi-bot deleted branch chore/drop-unused-gcp-key 2026-09-14 15:35:37 +00:00

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

sean/platform-seanfarm!682

No description provided.