In 109. Configure secrets in applications the instructor said:
Here we have specified the data in plain text which is not very safe.
So while creating a secret with a declarative approach, you must specify the secret values in an encoded format.
Please don’t mislead the students into thinking encoding is a security feature. It is not. (Here it serves for being able to use all characters in passwords, which would otherwise not be possible.) This level of incomprehension is concerning.
Starting at 05:30 in this video, he explains there why secrets are not secure. The only effective way to secure secret content within the cluster is with careful use of RBAC, and if you ever do the CKS killer shell test, there is a very interesting question on how to find ways to circumvent RBAC rules that aren’t cast-iron as if you were a penetration tester.
The safest way to pass secrets to applications is by coding them specifically to be able to interact with secure secrets management solutions like those offered by the big cloud providers if running the cluster in cloud, or using something like Hashicorp Vault.
you’re right about that part at 5:30 (I saw it only afterwards). Still, the part at 2:48 that I am referring to is misleading. I suggest you consider removing it. Or even better: How about replacing it by explaining the actual reason for the encoding?
I’d like to challenge your opinion: The safest way is keeping the secrets (or any of your data for that matter) on prem. This eliminates the attack vector of a provider having physical access to your hardware. Also, you control the whole software stack used to secure your secrets. I wouldn’t trust any provider, especially not just because it’s big. They all have failed already, MS with Azure being the worst, but not the only one.