0

I am devops engineer and project admin in Google Cloud project. Organization has some super sensitive keys that should be accessed by containers running in Kubernetes or Cloud Run, but they should not be accessible by me.

So far I see Secrets Manager and KMS as possible solutions. I have admin permissions for this project, so probably these secrets should be stored in another project owned by CTO and cross-referenced.

Also I have all permissions for monitoring running containers, is there any way to prevent secrets from leaking to me in runtime? And what solution should be used?

Dmitriy Zhukov
  • 372
  • 2
  • 12

1 Answers1

1

If you are project owner, you can't technically prevent the secret leak.

If the secret is stored in another project, you can't access the secret through the UI. However, that also means a service account has access to the secret stored in another project. Because you are project owner, you can impersonate the service account which has the right to access the secret, and access it also.

The only way to solve that issue, is the least privilege principle. Have only the minimal permissions on the project, and not the security admin role.

When you have to grant permission on service account, you need to use automated system, like CI/CD and terraform for example. And of course, each update need to be reviewed by another person, you can't update the CI/CD pipeline and grant permission to yourselves (such as service account impersonation) without peer review.

guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76