Security of letting Spinnaker deploy Kubernetes secrets

Hey folks,

The Best Practices for the Kubernetes Provider V2 document suggests to let Spinnaker deploy secrets. However, I’m finding that when I do that, I can easily see the secrets in cleartext in Deck – For example, by clicking on the YAML link in the stage that deployed the secret (it’d be under the kubectl.kubernetes.io/last-applied-configuration annotation). Is this a problem with the way Spinnaker is configured or is this working as intended?

I’d love to use the functionality that comes from using secrets as first-class artefacts on Spinnaker, but I’m not convinced it’s worth the risks. Apart from this feature request to improve the way secrets are handled, which only has two :+1:s (one of which is mine), no-one else seems to be concerned about this – So maybe I’m missing something here?

I know I can get an external tool to kubectl apply the secret, and I’ve got it working with Kapitan, but if the best practice is to let Spinnaker do that I’d expect that approach to be secure.

Cheers.

We have Spinnaker deploy Bitnami Labs Sealed Secrets CRD’s as a regular Deploy Manifest stage (artifact from git repo).

Positives:

  • Sealed secrets are encrypted and committed to git
  • Can’t see unencrypted secret in git or Spinnaker
  • Sealed Secrets controller in cluster decrypts SealedSecret and creates regular k8s Secret.
  • No app changes required like Hashicorp Vault would require.

Negatives:

  • Git PR review of secret not possible because encrypted
  • Pods won’t be restarted to pick up a new SealedSecret without something like Reloader/etc.
  • There is no version hydration of the Deployment secret reference like what happens with ConfigMap and Secrets by default (versioned). SealedSecret CRD must be versioned: false.

Hope that helps.
Karl

1 Like