FR: Allow option to disable key rotation on existing roleset binding updates

[ugirirajan]

Currently, any changes to roleset bindings recreates the Service Account and deletes any key created before.

Would be great if an option is enabled in vault to disable the behaviour.

To replicate with vault CLI

vault write gcp/roleset/test-roleset \
    project="${GOOGLE_CLOUD_PROJECT}" \
    secret_type="service_account_key"  \
    bindings=-<<EOF
resource "//cloudresourcemanager.googleapis.com/projects/${GOOGLE_CLOUD_PROJECT}" {
  roles = ["roles/storage.admin"]
}
EOF

vault read gcp/roleset/test-roleset  -format=json | jq .data.service_account_email
"vaulttest-role-1573455642@test-project-08a0b81a.iam.gserviceaccount.com"

Now update the same roleset with additional resource bindings.

vault write gcp/roleset/test-roleset \
    project="${GOOGLE_CLOUD_PROJECT}" \
    secret_type="service_account_key"  \
    bindings=-<<EOF
resource "//cloudresourcemanager.googleapis.com/projects/${GOOGLE_CLOUD_PROJECT}" {
  roles = ["roles/storage.admin","roles/bigquery.admin"]
}
EOF

vault read gcp/roleset/test-roleset -format=json | jq .data.service_account_email
"vaulttest-role-1573455642@test-project-08a0b81a.iam.gserviceaccount.com"

Would be great if a flag is added (ON/OFF) as CLI parameter to disable recreation of service account and retain existing keys.

[emilymye]

@sungiri88

I'm interested in this use case, and whether a separate use case like #60 would work instead for you. This current behavior is intentional because bindings are linked to the service account name - if we don't rotate the service account name, any old secrets will suddenly pick up new permissions. Our intention with this endpoint was to create credentials that can be viewed separate from an account, basically credentials with a set of IAM roles. The general pattern we've seen with Vault dynamic credentials is that if a user's credentials are revoked at any point (even before the lease is up), they can request a new credential from the same endpoint.

[ugirirajan]

Old secrets should pick up new permissions and that option can be given to the owners by flag.

[lukehau]

@emilymye

The integration pattern you mentioned works well for real-time services but doesn't work so well in some batch processing scenarios where you have operations that may last for many hours. In those situations I want to be able to update a roleset binding without having to consider whether or not the batch process is running.

#60 could solve the issue but that would mean manually provisioning the service account - which would suck for implementations that rely on Vault doing all the service account provisioning.