When a Pod has admin access, it means that the container within the Pod has access to the host system and can potentially perform privileged operations. This can be a security risk as an attacker could potentially exploit this access to gain control of the underlying host system.There are different levels of admin access for a Pod/container, such as:Running as the root userMounting the host file systemUsing privileged container settingsUsing host networking modeAll of these could increase the attack surface and should be avoided if possible.
To remediate the issue of a Pod with admin access, you can take the following steps:
- Avoid running containers with root privileges by specifying a non-root user in the container specification, using the USER directive in the Dockerfile, or using a security context in the Pod specification.
- Avoid mounting the host file system by using container-specific volumes instead, or using a securityContext setting in the Pod specification to disable hostPath and hostIPC.
- Avoid using privileged container settings by using non-privileged container settings instead, or by using a securityContext setting in the Pod specification to disable privileged mode.
- Avoid using host networking mode by using the bridge network mode instead, or by using a securityContext setting in the Pod specification to disable host networking.
Additionally, you can use Kubernetes RBAC (Role-Based Access Control) to limit the permissions of the Pod and its containers. You can also use Kubernetes network policies to restrict network traffic to and from the Pod. Finally, you can use Kubernetes Pod security policies to enforce security settings for Pods, such as restricting the use of privileged containers, host networking, and host file system access.
Note: Remediation steps provided by Lightlytics are meant to be suggestions and guidelines only. It is crucial to thoroughly verify and test any remediation steps before applying them to production environments. Each organization's infrastructure and security needs may differ, and blindly applying suggested remediation steps without proper testing could potentially cause unforeseen issues or vulnerabilities. Therefore, it is strongly recommended that you validate and customize any remediation steps to meet your organization's specific requirements and ensure that they align with your security policies and best practices.
