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 → bit.ly/2TYdHiS
Application-layer Secrets Encryption → bit.ly/2Uhn7v7
Watch more:
Next '19 Hybrid Cloud Sessions here → bit.ly/Next19HybridCloud
Next ‘19 All Sessions playlist → bit.ly/Next19AllSessions
Subscribe to the GCP Channel → 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;

[@evansoenke9026]

Very complex topic, expertly delivered explanation

[@rafau99]

how will you edit the values in secrets and push them to repo? once you get the secret it's only encrypted with base64 so no encryption at all; or will you not push it to repo and manually , edit every time you want to change

[@DustinDeus]

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.

[@tunminster]

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?

[@whykoks]

Secret sprawl?

[@guruprashanth_k]

thats the reason why we need something like KMS because kubernetes secret are plain text that are stored at etcd level. correct me if I am wrong.

[@nikolaykostadinov7108]

I still can't get his base64 joke

[@chaulaode]

can i have the slide?

[@shayberkovich8104]

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.

[@cptechno]

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

[@shayberkovich8104]

You run kubectl from master node usually. This is protected by the same mechanisms as, say, access to root on host. If attacker has access to kubectl there is no point of making distinction between secrets and other K8 objects.