Using secrets automation in production environments

priscilasolis

Our team wants to use Secrets Automation as a way to get items from 1Password and add those values as environment variables in Kubernetes using the Kubernetes Operator. We want to have Vaults per environment, so that would mean that we would have a single vault for production purposes. If the operator included in the cluster is deployed on an external machine, this means that someone else who has access to the machine might be able to potentially get the API token and with it, list items in the Vault, which includes sensitive information.

Is there a way to restrict the scope of the API token to avoid performing certain actions like listing items? Or are there any suggestions for the approach we want to take?

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided

Joris_1P

Hi @priscilasolis ,

Having a separate vault for your production environment sounds like a great idea. Will there also be a separate operator for each environment?

It is currently not possible to restrict a token to reading but not listing items. The security value of that will probably be limited because vault and item ID's are generally not considered to be secret. If someone has access to the token used by the operator, it is very likely that they can also obtain the ID's of the items that it uses.

For the overall best security posture, I would recommend the following:

• Use a separate operator (and therefore Connect token) for each environment.
• Only place items that are used by the operator in the vault(s) the operator has access to.
• Limit the number of users and services that have access to the configuration of the operator and the namespaces that the operator is watching.

Let me know if that answers your question.

Joris