An organization's admin can't set its repositories' secrets.dev.knotless.putSecret, deleteSecret and listSecrets take the caller's service token as the repository's owner, so only the account that owns the repository can call them. An org repository is owned by the org's account, and an admin's token is the admin's own, so knotless secret <org url> set NAME either fails or leaves secrets nobody's runner reads. An admin would need the org's own login.
One way: the appview lets an admin of the owning org (as it knows from org_member) put, list and delete for it, and the CLI seals with the org's DID as the owner in the associated data, as now. The runner side needs nothing new.
A runner on the owner's own account can't open the owner's secrets.listSecrets answers the owner with every secret and no value, and anyone else with those sealed to them, values included. A runner that logs in as the owner gets the owner's answer, so it never sees a sealed value and is given nothing; it can only use its --secrets file (docs/design/runner.md, Secrets).
One way: to the owner, listSecrets also returns sealed on the rows sealed to the caller. Only the runner's key opens them, and the owner who is that runner already holds it.
Neither blocks the hosted runner, whose account is its own and whose repositories so far belong to people, not orgs.
chadtmiller.com/knotless
What happened
Sealed secrets (
knotless secret, from Owners give their runners secrets with knotless secret) leave out two kinds of owner.An organization's admin can't set its repositories' secrets.
dev.knotless.putSecret,deleteSecretandlistSecretstake the caller's service token as the repository's owner, so only the account that owns the repository can call them. An org repository is owned by the org's account, and an admin's token is the admin's own, soknotless secret <org url> set NAMEeither fails or leaves secrets nobody's runner reads. An admin would need the org's own login.One way: the appview lets an admin of the owning org (as it knows from
org_member) put, list and delete for it, and the CLI seals with the org's DID as the owner in the associated data, as now. The runner side needs nothing new.A runner on the owner's own account can't open the owner's secrets.
listSecretsanswers the owner with every secret and no value, and anyone else with those sealed to them, values included. A runner that logs in as the owner gets the owner's answer, so it never sees a sealed value and is given nothing; it can only use its--secretsfile (docs/design/runner.md, Secrets).One way: to the owner,
listSecretsalso returnssealedon the rows sealed to the caller. Only the runner's key opens them, and the owner who is that runner already holds it.Neither blocks the hosted runner, whose account is its own and whose repositories so far belong to people, not orgs.