Ever faced a Kubernetes-related security incident? Don’t get alarmed; you’re just one among 94% of engineers who battle cloud-native security challenges.
Exposing nodes directly to public networks is a bad idea. The best place for them is a separate network that has no direct connection to the general corporate network.
Another isolation best practice is to separate Kubernetes control and data traffic. You don’t want them to flow through the same pipe. Open access to the data plane = open access to the control plane.
2. Steer clear of forbidden types
Avoid using forbidden types such as NodePort or LoadBalancer. Instead, expose services through ClusterIP to prevent malicious actors from discovering cluster infrastructure components.
3. Don’t mount container runtime sockets
Does your deployment have container runtime (CRI) sockets mounted in containers?
docker.sock, containerd.sock, and crio.sock increases the chance of an attacker gaining root access privileges for the host and the respective container runtime. To avoid this, remove the /var/run/<CRI>.sock hostPath volume.
4. Use a read-only root file system
Run K8s using a read-only root file system to prevent malicious binaries from writing to a system or worse, carrying out a system takeover.
You can make sure that containers use only the read-only filesystem by setting readOnlyRootFilesystem to true in the Pod securityContext definition.
5. Secure control plane access
To get an extra layer of security features like multi-factor authentication, get a third-party authentication provider.
For maximum security, avoid managing users at the level of the API server level. Instead, use a solution from cloud providers like AWS Identity and Access Management (IAM).
If you can’t get CSP IAM, choose OpenID Connect (OIDC) alongside an SSO provider you’re familiar with (more on that in K8s documentation).
6. Don’t forget about securing access to etcd
Access to etcd is equivalent to root permission. It’s the most important piece to secure within the control plane.
Ensure that communication with etcd is encrypted and that clients use certificate-based authentication. In an ideal world, only the API server should be able to access etcd. This would reduce the attack surface.
7. Use Kubernetes Role-Based Access Control (RBAC)
Take advantage of RBAC to set who has access to the Kubernetes API and, once they’re in, which permissions they have. You’ll find RBAC enabled by default in Kubernetes version 1.6 and up.
Since K8s brings together authorization controllers, you can disable the legacy Attribute Based Access Control (ABAC) when RBAC is on.
When setting permissions, pick namespace-specific ones over cluster-wide ones. Even when your team is busy debugging, it’s better not to give anyone cluster administrator privileges. Otherwise, your cluster’s security may become compromised.
8. Encrypt secrets
Did you know that secrets aren’t actually encrypted at rest by default in base Kubernetes implementations? If you use a Kubernetes-managed service like GKE, secrets are encrypted at rest.
Why is encrypting secrets important? If anyone intercepts your key-value store, they’ll get access to everything in your cluster. This includes all cluster secrets in plain text. Encrypting the cluster state store is the best way to secure your cluster against data-at-rest exfiltration.
9. Avoid deploying objects to the default namespace
In Kubernetes, namespaces provide a mechanism for isolating resource groups within one cluster. They’re a great use case for environments where many users are spread across multiple teams or projects.
All the objects that have no namespace assigned to them end up in the default namespace. That makes it easier to deploy malicious containers close to your most critical workloads. I recommend creating namespaces for objects in your deployment.
10. Create a rolling update strategy
To keep your EKS security airtight, build a rolling update strategy. Rolling updates allow deployment updates to minimize your application downtime thanks to incremental pod updates. Check out this page in the Kubernetes docs for more information.
Another point is running a vulnerability scan at runtime. Your cluster faces the risk of supply chain attacks. To handle them, you need to understand what really got into your cluster – even if you scanned all the deployment artifacts during CI/CD. Agent-based security solutions are good here – or even better than “agentless” ones.
Fingers crossed 🤞 the list above keeps you safe and secure.
Cheers,
Allen from CAST AI
CAST AI Group Inc., 111 NE 1st Street, 8th Floor #1041, Miami,Florida,33132,United States,