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.
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.
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?
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
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.
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.
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.
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?
Secret sprawl?
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.
can i have the slide?
Very complex topic, expertly delivered explanation
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
This presentation does not talk about "secret" like ...kubectl create secret .... How is the latter protected?
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.
I still can't get his base64 joke