Securing Secrets in the GitOps era

Your Kubernetes secrets are just base64 encoded, not encrypted. Learn a multi-layered strategy to truly secure them in a GitOps workflow.

#1about 6 minutes

Defining secrets and the layers of security

Secrets are defined using analogies from music to illustrate that security is built in layers, like an onion, with no single silver bullet solution.

#2about 8 minutes

How GitOps streamlines the application delivery process

GitOps is presented as a DevOps methodology where Git serves as the single source of truth for both application code and infrastructure configuration.

#3about 4 minutes

The risk of exposing credentials in Git repositories

A live demo with Argo CD highlights the common mistake of committing plain text credentials and explains why Kubernetes' base64 encoding is not a secure solution.

#4about 8 minutes

Using Sealed Secrets to safely store secrets in Git

The Sealed Secrets project provides a way to encrypt Kubernetes secret manifests before committing them to a public or private Git repository using a public/private key pair.

#5about 6 minutes

The vulnerability of unencrypted secrets within etcd

Even with Sealed Secrets, decrypted secrets are stored in plain text in etcd, creating a vulnerability that can be addressed with Kubernetes' encryption-at-rest feature.

#6about 5 minutes

Integrating an external KMS for robust etcd encryption

To improve on native encryption-at-rest, a Key Management System (KMS) plugin offloads encryption to an external service like HashiCorp Vault, separating keys from the cluster.

#7about 11 minutes

Eliminating secret exposure with direct memory injection

The most secure approach involves applications fetching secrets directly from a secret store like Vault at runtime, holding them only in memory to avoid exposure via files or environment variables.

#8about 11 minutes