Repository navigation
The reader secret is the owner's, as the other keys are - #136
Merged
Merged
Conversation
The 0.38.0 module made chat-reader-secret itself, a random password into Secret Manager with an accessor grant for chat-run, and the first host to deploy with sign_in stopped at terraform apply: the hosts' deploy identity, from the MCP host's shared bootstrap, holds no Secret Manager admin role by design, so it may not create a secret. The module now treats the reader secret as it treats chat-anthropic-key and typesafe-key. signin.tf, which held only the password, the secret, its version and the grant, is gone, and with it hashicorp/random, which nothing else used; run.tf still mounts CHAT_READER_SECRET from chat-reader-secret, latest version, only with sign_in, and says why the secret is the owner's. The README's deploy section gains the sign_in paragraph with the owner's three commands, once per project before the first deploy with sign_in, the value generated on the machine and never shown, and says that rotating it gives every reader a fresh month. The design's ruling now says the owner makes the key. The module's sign-in tests assert the mount by name with sign_in and its absence without; the Secret Manager API stays enabled, since the two older secrets need it. Verified: npm test (391 pass), typecheck, build:check, terraform init -backend=false and validate for google and azure, terraform fmt -check -recursive deploy, terraform test in deploy/google/terraform (7 pass, and each new assertion fails when the mount's name or its condition is broken), conventions-check and conventions-format pass. Process: Delivery Phase: Implement Track: Code Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
robertblust/mcp-blust-ch's chat deploy (run 40124879800) stopped at
terraform applywithError 403: Permission 'secretmanager.secrets.create' deniedonmodule.chat.google_secret_manager_secret.reader_secret[0]. The hosts' deploy identity comes from companygraph/mcp-server's shared bootstrap and holds no Secret Manager admin role by design, and every other secret the module reads,chat-anthropic-keyandtypesafe-key, is the owner's, made by hand and only mounted here. This makeschat-reader-secretthe owner's in the same way.deploy/google/terraform/signin.tf, which held only therandom_password, the secret, its version and the accessor grant, is removed, and with ithashicorp/randomfromrequired_providers, which nothing else used.run.tfstill mountsCHAT_READER_SECRETfrom secretchat-reader-secret, versionlatest, only whensign_inis set, with a comment in the style of the Anthropic key's. The Secret Manager API stays enabled, since the module enabled it for the two older secrets. The module's sign-in tests now assert the mount by name withsign_inand its absence without; each assertion fails when the mount's name or its condition is broken. The README's deploy section gains asign_inparagraph with the owner's three commands, run once per project before a host's first deploy withsign_in, the value generated on the machine and never shown, and says that rotating it gives every reader a fresh month. The design's ruling in section 11 now says the owner makes the key.docs/INTERFACE.mdsaid nothing about where the secret comes from and is unchanged. package.json is not bumped; the release is a separate PR.A host that already ran a failed 0.38.0 apply has a
random_password.reader_secretin its state; 0.38.1's plan removes it, a local-only resource with nothing in Google Cloud.Verified:
npm test(391 pass),npm run typecheck,npm run build:check,terraform init -backend=falseandvalidatefordeploy/google/terraformanddeploy/azure/terraform,terraform fmt -check -recursive deploy,terraform testindeploy/google/terraform(7 pass),sh conventions/conventions-checkandsh conventions/conventions-formatpassed.🤖 Generated with Claude Code