feat(vault): DigitalOcean overlay with GCP Cloud KMS auto-unseal - #53
Merged
Conversation
DigitalOcean has no managed KMS, so auto-unseal there has no in-provider option: either an external KMS, or operator-held unseal shares re-entered on every pod restart. This standardises on GCP Cloud KMS via seal "gcpckms". Vault reaches that key through Workload Identity Federation — a projected ServiceAccount token, audience-scoped to the WIF provider, exchanged for a short-lived Google token. No service account JSON key exists, so none can leak. The credential configuration file describing the exchange carries no private key (Google documents it as non-confidential), which is why it mounts from a ConfigMap rather than a Secret. The file carries only what platform-root does not inject, mirroring vault-aws.yaml. Additive: no existing file changes, and no AWS or Azure deployment loads it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Primeiro passo do suporte a DigitalOcean. Puramente aditivo — nenhum arquivo existente muda, e nenhum deployment AWS ou Azure carrega este overlay.
Por que GCP KMS num cluster DigitalOcean
A DigitalOcean não tem serviço gerenciado de KMS. Para auto-unseal sobram duas opções: um KMS externo, ou o operador redigitando unseal shares a cada restart de pod. Este PR padroniza a primeira.
A dependência cross-cloud é real e está dita no arquivo: um Vault na DigitalOcean não abre enquanto o Google KMS estiver inalcançável. É a mesma forma de dependência que AWS e Azure já têm com o KMS deles — só que atravessando nuvem.
Sem credencial estática no cluster
Vault autentica no Google por Workload Identity Federation: token projetado da ServiceAccount, com audience escopada ao provider da federação, trocado por token de curta duração que impersona a service account com encrypt/decrypt na chave. Não existe JSON de service account, então não há o que vazar nem rotacionar.
O arquivo de configuração de credencial não carrega chave privada — o Google o documenta como não-confidencial — por isso ele monta de ConfigMap e não de Secret.
Escopo
Este arquivo carrega só o que o platform-root não injeta, espelhando
vault-aws.yaml. A stanza de seal e a fiação da federação vêm no PR correspondente doestabilis-platform.Permissões exigidas na chave, conforme a doc do
gcpckmsdo Vault:cloudkms.cryptoKeyVersions.useToEncrypt,useToDecrypt,cloudkms.cryptoKeys.get.