Skip to main content

​
Secrets the platform owns

Some secrets are created by a service that then reads the value back and acts on it — a managed database’s generated user password, for instance. Those come back with managed: true. You can read them and you can delete them. PUT-style writes are refused with 403 SECRET_PLATFORM_MANAGED:
  • POST .../value — overwriting the value would not change whatever the value describes, it would make the two disagree, turning a credential the platform trusts into customer-supplied bytes.
  • PATCH /v1/secrets/{id} — including tags, because tags feed the conditions IAM policies are written against. Retagging a secret the platform reads back would let a caller move it in and out of the scope of their own policies.
The flag is on the wire so a client can explain the refusal before making the call rather than after.