vault-k8s can be used for syncing the sensitive data from vault backend to business pod, by reading the document here I. found the sensitive data will be mounted into pod as plain text file, so my question is since the sensitive data file is still available when entering the pod. is there any safer way to protect them. such as decrypt the data in application memory only.
Not really, no.
It is important to take note that:
-
Using a Vault agent sidecar is a technique that specifically exists to make it easy to fetch secrets and provide them to applications which don’t themselves know about Vault and expect to receive configuration in regular files. As soon as you decide you want the application itself to participate in the security, it might as well communicate directly with the Vault API, and remove the need for a sidecar entirely.
-
If you can enter the pod, the security is already broken. You can now read authentication material such as the Kubernetes service account JWT directly from disk, and use that to authenticate to Vault yourself, and read whatever you like with the identity of the application.
Thanks for you reply, I agree with you on both of your points, what I metioned in the question is more about to reduce the possiblity of exposing sensitive data during the pod whole life, I mean even the the pod has been entered by the bad guyes, he still can not get the sensitive data, so is there any technology/library/sdk can be used for such things?
If someone can get into a pod they would have breached most of the security.
As @maxb mentioned Kubernetes exposes things to the pod such as the JWT which can then be used to access the Kubernetes API as the pod or login to Vault. At that point the “bad person” looks no different from the real application, so could lookup any secrets they wanted.
A compromise where someone ends up inside a pod with the ability to run commands & read files is a very bad breach.
@maxb @stuart-c So is it possible to configure how long will the mounted configuration file would live? Reduce the lifetime of sensitive data would also be helpful 
, but I can’t find any annotation keys defined in the document website here
Ok I found it’s already described as following in the document here:
Once the sink writes the file, it is up to the client to control lifecycle; generally it is best for the client to remove the file as soon as it is seen.
It is also best practice to write the file to a ramdisk, ideally an encrypted ramdisk, and use appropriate filesystem permissions. The file is currently written with 0640 permissions as default, but can be overridden with the optional 'mode' setting.