Managing sensitive data using Secret resources
We should always avoid adding sensitive information to our application images. Neither passwords, connection strings, tokens, certificates, nor license information should be written inside container images; all this content must be included in the runtime. Therefore, instead of using ConfigMap resources, which are stored in clear text, we will use Secrets. Kubernetes Secret resource content is described in base64 format. They are not encrypted, and anyone with access to them can read their data. This includes any user who can create a Pod in the same namespace, as the Secret can be included and hence read. Only appropriate RBAC resource access can ensure Secrets’ security. Therefore, it is important to understand that you should avoid access to your Secret resources using appropriate Kubernetes Roles and RoleBindings (Kubernetes RBAC). Also, by default, Kubernetes doesn’t encrypt Secrets in etcd, hence access to the key-value...
