Kubernetes Secrets are secure objects which store sensitive data, such as passwords, OAuth tokens, and SSH keys, etc. with encryption in your clusters. “Kubernetes supports some default secret types like “kubernetes.io/ssh-auth” to store credentials for SSH authentication, “bootstrap.kubernetes.io/token” for bootstrap token data, and “kubernetes.io/service-account-token” to keep service account tokens. You may also create a new secret type and use it to store any security-critical data.
When you use secrets, you don’t have to store confidential information directly on the file system or hardcode it in source code. By default, unencrypted secrets are stored inside Kubernetes’ key-value store, etcd. Safe usage of secrets requires:
There are two ways to consume secrets inside a pod: as files inside mounted data volumes or as environment variables. To mount secret files, you have to add a volume to your pod definition and modify your image such that applications search for secret files in the right directory. It’s also recommended to set the appropriate file permissions for secret files.
When you use environment variables, you have to modify the pod definition to include the environment variable and then change your image so that your applications retrieve secrets from the right variable. Secrets will appear as normal environment variables inside the container.
Since environment variables provide a relatively easier and convenient way of storing and accessing secrets, developers may prefer them over mounted secret files. However, it isn’t recommended from a security standpoint.
A controller is creating containers that use secrets mounted as environment variables. It is reasonably common for application code to log out its environment, particularly in the event of an error. This will include any secret values, passed as environment variables. If a malicious actor gets access to the asset, and in turn, the application logs, they can use the exposed secrets to compromise the larger system.
With support for CIS Kubernetes benchmarks, Orca will give you details of passed and failed control checks with extensive details around failed checks for the cloud infrastructure plane and Kubernetes Pods.
With Orca’s agentless design, you also gain two important advantages: complete 100% visibility of both the Kubernetes control plane nodes, the Pods, and the containers within them. Orca can even scan containers for vulnerabilities in pods that are either paused or stopped. In this specific case (as seen in the above screenshot), Orca has detected that the controller system-monitor-deployment creates containers that use secrets mounted as environment variables.
Modify application code to read secrets from mounted secret files instead of environment variables.
Audit for containers that consume secrets via environment variables and replace the environment variables with mounted secret files.
Configure and use encryption for secrets at rest.
Use RBAC authorization to limit read and write access to secrets.
Use a logging framework to monitor and analyze Kubernetes and OS logs.
Orca Security, the cloud security innovation leader, provides cloud-wide, workload-deep security and compliance for AWS, Azure, and GCP － without the gaps in coverage, alert fatigue, and operational costs of agents.
Lateral movement