You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wanted to see if there had been any previous consideration to allowing creating rolesets for service accounts that are created outside of this GCP secret engine? And if not, would it be something others would find useful.
An obvious downside is that if a service account was deleted, it would break the roleset. But that is no different from the current risks of the GCP secrets engine.
My main use case which prompts this discussion is that we have multiple Vault clusters running across various cloud providers configured with the GCP secrets engine for a given GCP project. Unfortunately, with rolesets being consistently configured across all Vault clusters, this results in a large number of unused service accounts and we more quickly need to request a service account quota increase with GCP.
Being able to configure a roleset with a service account that is managed outside of this secrets engine additionally would allow us to avoid HTTP 409 conflicts of service accounts created with the same unix timestamp (see #81) and it would allow us to avoid an HTTP 409 conflict when multiple Vault clusters try to update the IAM policy on a GCP project.
The text was updated successfully, but these errors were encountered:
I wanted to see if there had been any previous consideration to allowing creating rolesets for service accounts that are created outside of this GCP secret engine? And if not, would it be something others would find useful.
An obvious downside is that if a service account was deleted, it would break the roleset. But that is no different from the current risks of the GCP secrets engine.
My main use case which prompts this discussion is that we have multiple Vault clusters running across various cloud providers configured with the GCP secrets engine for a given GCP project. Unfortunately, with rolesets being consistently configured across all Vault clusters, this results in a large number of unused service accounts and we more quickly need to request a service account quota increase with GCP.
Being able to configure a roleset with a service account that is managed outside of this secrets engine additionally would allow us to avoid HTTP 409 conflicts of service accounts created with the same unix timestamp (see #81) and it would allow us to avoid an HTTP 409 conflict when multiple Vault clusters try to update the IAM policy on a GCP project.
The text was updated successfully, but these errors were encountered: