Secret Access Control

Secret access control defines which authenticated identities or services may perform operations such as reading, creating, updating, or deleting particular secrets. It is a core authorization concern in secrets management and should enforce least privilege.

Authentication answers who an identity is; secret access control answers what that identity may do with a secret. For example, a backend service might be allowed to read a database password while a deployment service may be allowed to create or rotate it.

Access should be granted to specific identities, roles, or service accounts rather than broadly to everyone who can reach the secrets store. A useful policy distinguishes resources and operations, such as `read`, `create`, `update`, and `delete`.

Least privilege means granting only the permissions required for a task. A service that only needs to retrieve an API key should not automatically receive permission to delete or modify that key.

Authorization is normally enforced by the secrets-management system or an identity-aware access layer. Applications should also avoid placing secrets in source code, logs, exception messages, or other locations where broader permissions may expose them.

In Java backends, the application commonly authenticates to a secrets service using a workload identity, role, or service credential. The secrets service then evaluates that identity against its access policy before returning or modifying the requested secret.

Key points

• Authentication identifies the caller; authorization determines permitted secret operations.
• Grant permissions to specific identities, roles, or service accounts.
• Apply least privilege to both the secret resource and the allowed operations.
• Separate read access from write, rotation, and deletion privileges.
• Never treat possession of a secret as a substitute for authorization to access other secrets.

Interview questions

What is secret access control?

Secret access control is the authorization layer that determines which identities can perform operations on specific secrets. Typical operations include reading, creating, updating, rotating, and deleting. The policy should grant only the permissions required by each workload. This reduces the impact if an application identity is compromised.

Why is least privilege important for secrets?

Secrets can provide access to databases, APIs, infrastructure, or other sensitive systems, so unnecessary access increases the potential impact of a compromise. A service should receive only the secrets and operations it actually needs. For example, a service that only reads a database password should not be able to delete secrets. Least privilege also makes permissions easier to audit.

How would a Java service securely access a secret?

The service should authenticate using a workload identity or another managed identity mechanism rather than embedding a master credential in source code. The secrets manager can then evaluate that identity against an authorization policy. The policy should grant access only to the required secret and operation. The application should retrieve the secret at runtime and avoid exposing it through logs or error messages.

What permissions should you give a service that only needs to read one secret?

I would grant the service read access to that specific secret and avoid granting create, update, or delete permissions unless they are required. I would also avoid granting access to unrelated secrets. The identity should be specific to the service rather than a shared administrator account. This follows the principle of least privilege.

What is the risk of giving an application broad secret-manager permissions?

A compromised application identity could potentially retrieve or modify many secrets unrelated to its normal function. That can substantially increase the blast radius of a single compromise. Broad permissions can also allow destructive operations such as deletion or unauthorized rotation. Narrow resource- and operation-level permissions reduce these risks.