Skip to main content

Secrets Intro

Secrets demand special handling and they are often stored, managed, and configured in a workflow that is adjacent to application deployment.

Kubernetes allows you to decouple configs and secrets from your applications, but leaves the question open how those secrets show up in the cluster.

In this book, you will learn about two platform components that extend Kubernetes's secret facilities with secret management workflows.

Life is simple on localhost​

Developers know that configs and secrets must come from environment variables.

During development, configs and secrets are just that: environment variables.

But come deployment time, secrets become snowflakes​

Kubernetes offers the ConfigMap and Secret resource types to decouple configuration from deployment descriptors. Instead of storing environment variables verbatim in the yaml, you reference config maps and secrets by their name.

Life is simple with config maps. Even though you store them alongside your application descriptors, secrets demand special treatment. ❄

And special treatment means a special workflow. One that is distinct to app deployment​

I want to make it clear that Kubernetes does everything the right way when it comes to secrets.

Its abstraction allows for secret workflows that can treat secrets in a way that is in sync with your company's information security policies.

Because of this, secret workflows vary from company to company: I've seen

  • secrets put in CI
  • secrets put in cloud key stores, vaults
  • automations that unlock keys in CI
  • vaults that unseal in the cluster
  • dev workflows that include cloud CLIs, encrypted git repos, GUIs to punch in secrets

Sprinkle this with devops organizational divisions, and you often get an uncomfortable dev workflow.