Explain how permission actors and operations combine to enforce access control in CredHub?

Every CredHub credential (or, with V2 permissions, every matching path) carries an access-control list made up of entries, and each entry is nothing more than an Actor paired with a set of Operation values — READ, WRITE, DELETE, READ_ACL, WRITE_ACL.

When a request comes in, CredHub first determines the caller's identity from the authentication method — the certificate subject for mTLS, the token subject for OAuth2 — and turns that into an actor identifier like mtls-app:<guid> or uaa-client:<name>. It then checks whether any entry in the relevant ACL grants that exact actor the operation the request needs.

Access is deny-by-default: if there's no matching entry for that actor and that operation, the request is rejected, regardless of how the caller authenticated. This is why writing a credential and granting the consuming app's permission are treated as two separate steps — the app that will read a secret usually isn't the same actor as whatever wrote it, most commonly a service broker, so its read permission has to be granted explicitly, not inherited.