Repository navigation
Conversation
The agent has supported --signing-gcp-kms-key on agent start, pipeline upload, and tool sign since v3.121.0 (buildkite/agent#3660), but the signed pipelines page only covered AWS KMS. Add a GCP KMS section mirroring the AWS KMS structure: key creation, agent configuration, signing static steps, IAM permissions, and rotation. Also remove a stale <path to signing jwks> bullet from the AWS KMS "Sign all steps" section that doesn't match the command above it. A-2027 Amp-Thread-ID: https://ampcode.com/threads/T-01a10f73-0a6f-727d-a4f5-1e90dc3404c7 Co-authored-by: Amp <amp@ampcode.com>
![buildsworth-bk-app[bot]](https://avatars.githubusercontent.com/in/3010600?s=60&v=4){kind=small}
There was a problem hiding this comment.
The algorithm table needs a version caveat to avoid rejecting validly signed jobs on older supported agents. I also flagged a configuration value that fails when copied literally.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 36868, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
About buildsworth
Model: gpt-6.1-sol with xhigh thinking.
How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.
Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. Unless repository policy already allows L2 approval, grant it by mentioning @buildsworth-bk (see approval ceiling and L2 approval grant):
- L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
- L2 — Standard risk (new UI, additive API fields, refactors). Approved only when repository policy or a verified grant allows it; otherwise comment-only.
- L3 — High risk (auth, migrations, payments, secrets, perf-critical pipeline paths). Human approval required unless repository policy explicitly allows L3 approval; per-PR grants cannot allow it.
…fication-failure-behavior placeholder Agent versions before 3.136.0 (go-pipeline < 0.18.0) verify KMS signatures as ES256 regardless of the key's algorithm, so only EC_SIGN_P256_SHA256 keys work there. Also replace the literal <warn> placeholder, which the config parser keeps as-is and the job runner rejects, with warn in all three sections. Amp-Thread-ID: https://ampcode.com/threads/T-01a10f73-0a6f-727d-a4f5-1e90dc3404c7 Co-authored-by: Amp <amp@ampcode.com>
There was a problem hiding this comment.
Both previous findings are fixed, and I found no new issues.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 36877, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
Superseded by a newer Buildsworth review.
This branch has not been deployed
2 participants
Why
The agent has supported GCP KMS for signed pipelines since v3.121.0 (buildkite/agent#3660), but the Signed pipelines page only documents self-managed JWKS keys and AWS KMS. A customer recently proposed GCP Secret Manager support in buildkite/agent#4378 because they didn't know GCP KMS was already an option.
What
Adds a "GCP KMS managed key setup" section following the structure of the AWS KMS section, based on the agent source (
internal/cryptosigner/gcp/kms.go,clicommand/agent_start.go,clicommand/tool_sign.go,clicommand/pipeline_upload.go):gcloud, and the key version resource name format thesigning-gcp-kms-keysetting requires (projects/*/locations/*/keyRings/*/cryptoKeys/*/cryptoKeyVersions/*).BUILDKITE_AGENT_SIGNING_GCP_KMS_KEY(agent start) andBUILDKITE_AGENT_GCP_KMS_KEY(tool sign,pipeline upload) environment variables, and Application Default Credentials for authentication.useToSignandviewPublicKey(roles/cloudkms.signerVerifier); verifying agents need onlyviewPublicKey(roles/cloudkms.publicKeyViewer) because the agent fetches the public key and verifies locally.Also removes a stale
<path to signing jwks>bullet from the AWS KMS "Sign all steps" section (the command above it has no such flag), and mentions KMS in the page's LLM description.The agent CLI help partials and
agent_attributes.yamlalready include--signing-gcp-kms-keybecause they are generated from the agent, so no changes there.Linear: A-2027