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.
@evansoenke90264 жыл бұрын
Very complex topic, expertly delivered explanation
@rafau994 жыл бұрын
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
@tunminster4 жыл бұрын
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?
@whykoks4 жыл бұрын
Secret sprawl?
@guruprashanth_k3 жыл бұрын
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.
@shayberkovich81044 жыл бұрын
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.
@cptechno5 жыл бұрын
This presentation does not talk about "secret" like ...kubectl create secret .... How is the latter protected?
@shayberkovich81044 жыл бұрын
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.