Kubernetes Platform Security

5 min readApr 5, 2021

Enterprises have prioritized security due to uptime and compliance concerns. Security-led development will be a priority for 90% of orgs by 2021.

Let’s discuss about how the micro services Kubernetes platform can be secured by implementing appropriate security solutions and controls.

Kubernetes platform security principles.

· Defense in depth.

· Least privilege.

· Limiting the attack surface.

It’s preferable to have multiple layers of defense against attacks on your Kubernetes cluster. If you’re relying on a single defensive solution, attackers might find their way around it.

There are various ways that an attacker could attempt to get access to your Kubernetes cluster, applications running on it.

Microservices environment team need to have security solutions at all layers of the Kubernetes platform

Automation and Configuration Management
Secure coding practices/Security as Code
Host Hardening
CI/CD for Patching
Application-level Auditing and Scanning
Automated Vulnerability Management Scanning
Automated Compliance Scan
Managing Secrets
Thread Modeling
Security code reviews
Penetration test

Kubernetes native features/solution components to secure your container platform

RBAC-Use Namespaces, role and role bindings , service accounts

Namespaces: Logical segmentation and isolation, or “virtual clusters”. Correct use of Kubernetes namespaces is fundamental for security, as you can group together users, roles and resources according to business logic without granting global privileges for the cluster

Service Accounts: Used to assign permissions to software entities. Kubernetes creates its own default service Accounts, and you can create additional ones for your pods/deployments. Any pod run by Kubernetes gets its own privileges through its service Account, applied to all processes run within the containers of that pod.

Start by making sure your cluster configuration supports RBAC. The location of the configuration file is your kube-apiserver manifest, and this depends on the deployment method but it’s usually inside /etc/kubernetes/manifests in either the master node(s) or the apiserver pod.

Look for this flag: –authorization-mode=Node,RBAC

2) Kubernetes admission controllers

An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. Admission controllers pre-process the requests and can provide utility functions (such as filling out empty parameters with default values), but can also be used to enforce security policies and other checks.

Admission controllers are found on the kube-apiserver conf file:

–admission control=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,ResourceQuota

3) Kubernetes Security Context

When you declare a pod/deployment, you can group several security-related parameters, like SELinux profile, Linux capabilities, etc, in a Security context block

4) Kubernetes Security Policy (Pod security Policy)

Kubernetes Pod Security Policy (PSP), often shortened to Kubernetes Security Policy is implemented as an admission controller. Using security policies you can restrict the pods that will be allowed to run on your cluster, only if they follow the policy we have defined.

5) Kubernetes Network Policies

A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints.

6) Kubelet security — access to the kubelet API

Verify the Kubernetes security settings when configuring kubelet parameters:

anonymous-auth is set to false to disable anonymous access (it will send 401 Unauthorized responses to unauthenticated requests).

kubelet has a `–client-ca-file flag, providing a CA bundle to verify client certificates.

`–authorization-mode is not set to AlwaysAllow, as the more secure Webhook mode will delegate authorization decisions to the Kubernetes API server.

–read-only-port is set to 0 to avoid unauthorized connections to the read-only endpoint (optional).

7) Securing Kubernetes etcd

etcd is a key-value distributed database that persists Kubernetes state. The etcd configuration and upgrading guide stresses the security relevance of this component:

“Access to etcd is equivalent to root permission in the cluster so ideally, only the API server should have access to it. Considering the sensitivity of the data, it is recommended to grant permission to only those nodes that require access to etcd clusters.”

You can enforce these restrictions in three different (complementary) ways:

• Regular Linux firewalling (iptables/netfilter, etc).

• Run-time access protection.

• PKI-based authentication + parameters to use the configured certs.

Run-time access protection An example of run-time access protection could be making sure that the etcd binary only reads and writes from a set of configured directories or network sockets, any run-time access that is not explicitly whitelisted will raise an alarm

8) Using a trusted Docker registry

Configure private Docker registry in Kubernetes

Kubernetes provides a convenient way to configure a private Docker registry and store access credentials, including server URL, as a secret:

kubectl create secret docker-registry regcred –docker-server=<your-registry-server> –docker-username=<your-name> –docker-password=<your-pword> –docker-email=<your-email>

9) Authentication ,authorization and Admission controllers for API

10) CI/CD Best Practices

Implement the security solutions at build,ship and run phases

Build a solutions for the below requirements and integrate it with your environment to secure the micros services platform

· End to end visibility of Kubernetes pods deployment

· Alert management solution to trigger alert when internal service pods or containers start to scan ports internally

· Monitoring solution to Monitor network connections

· Monitor what’s going on inside — pod, container?

· Reviewed access rights to the Kubernetes cluster to know potential insider attack vectors

· Security checklist — Kubernetes services, access controls, and container hosts?

With new tools and mentality, enterprises found means for achieving constant delivery (CD) and constant integration (CI) where software development lifecycles became much shorter. DevSecOps looks to combine DevOps and SecOps functions into one team that all work together to increase the rate of deployment while also ensuring compliance and security best practices are maintained. By making security a responsibility of every member of the team, development and operations take some of the load off of security.