Kubernetes is a complex platform and requires extensive configuration and management. To keep Kubernetes workloads safe, especially in a production environment, you need to address key architectural vulnerabilities and platform dependencies, by implementing security best practices.
In this article, you will learn about the following Kubernetes security best practices:
Runtime security helps protect workloads against a variety of threats that could emerge after containers have been deployed, such as:
- The activation of malware that is hidden inside a container image.
- Privilege escalation attacks in which a container exploits security bugs in the container runtime, Kubernetes, or the host OS.
- The deployment of unauthorized containers by an attacker who exploits a gap in an access control policy or a bug in Kubernetes.
Tools - Sysdig, Snyk
Use Role-Based Access Control (RBAC):
Role-based access control (RBAC) lets the customer control who can access the Kubernetes API and what permissions they have. RBAC is typically enabled by default in Kubernetes. However, if you upgraded from a very old Kubernetes release and had not enabled it earlier, RBAC settings should be checked to make sure they are enabled.
Network Security:
Because Kubernetes typically relies on a mix of internal resources (like kube-proxy) and external services (like CNI plugins and service meshes) to manage networking configurations and traffic, securing Kubernetes networks also requires admins to leverage a mix of native and third-party tools.
- Define Network Policies: Network policies define rules that govern how pods can communicate with each other at the network level.
- Service Meshes: In addition to CNI plugins, production Kubernetes clusters typically leverage a service mesh to help simplify networking. Most service meshes also provide network observability and security functionality. Service mesh provides defense with mutual TLS (mTLS) encryption of the traffic between your services.
Secrets Should Be Secrets:
Secrets contain sensitive data such as a password, a token or an SSH key. Kubernetes secrets help securely initialize pods with artifacts like keys, passwords, tokens, etc. When a pod starts up, it will generally need to access its secrets. Whenever a service account is created, a Kubernetes secret storing its authorization token is automatically generated. Kubernetes supports encryption at rest. This will encrypt secret resources in etcd, preventing access to your etcd backups and viewing the content of those secrets.
Tool - AWS Key Management Service (AWS KMS)
Protect etcd with TLS, Firewall and Encryption:
Since etcd stores the state of the cluster and its secrets, it is a sensitive resource and an attractive target for attackers. If unauthorized users gain access to etcd they can take over the entire cluster. Read access is also dangerous because malicious users can use it to elevate privileges. Encryption is crucial for securing etcd, and is not turned on by default. You can enable it via kube-apiserver process, by passing the argument –encryption-provider-config. Also, set up a firewall between the API server and the etcd cluster. For example, run etcd on a separate node and use Calico to configure a firewall on that node.
Implement Continuous Security Vulnerability Scanning:
Containers might include outdated packages with known vulnerabilities (CVEs). This cannot be a ‘one off’ process, as new vulnerabilities are published every day. An ongoing process, where images are continuously assessed, is crucial to insure a required security posture.
Tools - Kube Hunter, Kube Bench
Regularly Apply Security Updates to Your Environment:
Once vulnerabilities are found in running containers, you should always update the source image and redeploy the containers. Try to avoid direct updates (e.g. ‘apt-update’) to the running containers, as this can break the image-container relationship. Upgrading containers is extremely easy with the Kubernetes rolling updates feature - this allows gradually updating a running application by upgrading its images to the latest version.
Automated Backup and Restore:
Automated Backup and Restore of all Your Production Stateful Kubernetes Applications during - Accidental or Malicious Data Loss, Infrastructure or Hardware Failure, Application Misconfiguration, Compliance Audit Environment etc.
Disaster Recovery:
Granular Restores allows you to restore the application components you want and where you want them. An application can be cloned into the same or into a new namespace. You can also decide to restore only an application subset such as the data volume.
Tool - Kasten K10
Happy Hacking...Enjoy...
For educational purpose only...Do not misuse it...
