fix(infra): grant Secrets Officer to whoever is actually running the script - #112
Merged
Conversation
…script The vault grant resolved the caller with `az ad signed-in-user show`, which only answers for a human. Run as a service principal -- any CI invocation -- it returns nothing, and that empty id went straight into the role assignment whose failure was swallowed by `2>&1 | Out-Null`. The grant silently did not happen and the script continued, failing several steps later at the secret writes with an error pointing at the wrong thing. The caller is now resolved either way: signed-in user first, falling back to the service principal the CLI is authenticated as. If neither resolves, or if the role is absent afterwards, the script throws where the problem is rather than letting a later step fail for a reason that reads as unrelated. The end state is verified by querying the assignment, because `role assignment create` returns non-zero when the assignment already exists -- so neither exit code alone distinguishes "granted" from "was already granted" from "failed". Found while auditing the sibling repo's provisioning scripts after the same class of defect surfaced there (ToDoApp #166), where an ungated signed-in-user lookup under `set -e` killed the script outright. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The vault grant resolved the caller with
az ad signed-in-user show, whichonly answers for a human. Run as a service principal -- any CI invocation --
it returns nothing, and that empty id went straight into the role assignment
whose failure was swallowed by
2>&1 | Out-Null. The grant silently did nothappen and the script continued, failing several steps later at the secret
writes with an error pointing at the wrong thing.
The caller is now resolved either way: signed-in user first, falling back to
the service principal the CLI is authenticated as. If neither resolves, or if
the role is absent afterwards, the script throws where the problem is rather
than letting a later step fail for a reason that reads as unrelated. The end
state is verified by querying the assignment, because
role assignment createreturns non-zero when the assignment already exists -- so neither exit code
alone distinguishes "granted" from "was already granted" from "failed".
Found while auditing the sibling repo's provisioning scripts after the same
class of defect surfaced there (ToDoApp #166), where an ungated signed-in-user
lookup under
set -ekilled the script outright.Co-Authored-By: Claude Opus 5 noreply@anthropic.com