Securing Kubernetes Secrets (Cloud Next '19)



Secrets are a key pillar of Kubernetes’ security model, used internally (e.g. service accounts) and by users (e.g. API keys), but did you know they are stored in plaintext? That’s right, by default all Kubernetes secrets are base64 encoded and stored as plaintext in etcd. Anyone with access to the etcd cluster has access to all your Kubernetes secrets.

Thankfully there are better ways. This lecture provides an overview of different techniques for more securely managing secrets in Kubernetes, including secrets encryption, KMS plugins, and tools like HashiCorp Vault. Attendees will learn the trade-offs of each approach to make better decisions on how to secure their Kubernetes clusters.

Securing Kubernetes Secrets → http://bit.ly/2TYdHiS
Application-layer Secrets Encryption → http://bit.ly/2Uhn7v7

Watch more:
Next ’19 Hybrid Cloud Sessions here → https://bit.ly/Next19HybridCloud
Next ‘19 All Sessions playlist → https://bit.ly/Next19AllSessions

Subscribe to the GCP Channel → https://bit.ly/GCloudPlatform

Speaker(s): Seth Vargo, Alexandr Tcherniakhovski

Session ID: HYB200
product:Kubernetes Engine,Cloud KMS; fullname:Alexandr Tcherniakhovski,Seth Vargo; event: Google Cloud Next 2019; re_ty: Publish; product: Cloud – Containers – Google Kubernetes Engine (GKE); fullname: Seth Vargo;

source

8 thoughts on “Securing Kubernetes Secrets (Cloud Next '19)”
  1. Wrong definition of secret. Should have appended that it is a piece of text that cannot be known by others..

  2. 32:20 I'm still confused. From point of view of the KMS plugin, it must be authenticated with the KMS provider. What prevents attackers to issue new tokens when they have access to running VM?

    *UPDATE:* I got it. Kubernetes Service Accounts are used to assign pods the right to issue new KMS token to decrypt data for the application. This is indeed "magic" because Google Cloud IAM is used.

  3. I am fan of using kubernetes secret rather than Azure's Key vault or aws KMS or other third party key valut provider. why do i need to use the other key vault provider if kubernetes is already offered the similiar secret key stoarge?

  4. Not the best secret example at 7:53. Credit card numbers would be normally saved encrypted in database pod, not as a secret in Etcd. Now the password to that database pod would be a secret stored in Etcd.

  5. This presentation does not talk about "secret" like …kubectl create secret …. How is the latter protected?

Leave a Reply

Your email address will not be published.

Captcha loading...