In a Kubernetes environment, the control pane core element is the API server. It’s an HTTP API that manages all communication between your application’s different parts, from cluster segments to external components and end-users.
Kubernetes API also allows developers to query and modify Kubernetes API objects (i.e., Pods, Namespaces, ConfigMaps, Events, and more), so it’s critical to prevent any gaps in the API security.
The 2018 CVE-2020-8559, is a big and recent Kubernetes vulnerability that earned a worrisome 6.8 severity score (out of a maximum of 10) on the National Vulnerability Database. This high score stemmed from that CVE ability to enable a critical attack scenario:
In short, CVE-2020-8559n basically enabled any successful attacker to take full control of the targeted application.
CVE-2018-1002105 demonstrates how crucial solid Kubernetes API security is. As the Kubernetes API server is the core of Kubernetes’ control-pane, CVE-2018-1002105 effectively was a Kubernetes security risk affecting every single Kubernetes application.
Here are 9 Kubernetes security best practices updated from the CNCF 2019 version to help you maintain your Kubernetes API security.
Systematically upgrade to the latest version as soon as possible
New versions typically include security features in addition to bug fixes. Latest releases should always be run with the latest release to avoid falling behind with upgrades, as implementing upgrades becomes more complex when jumping up a few versions. In any case, upgrading to a new version on a quarterly basis is highly recommended to limit extended exposure to newly patched vulnerabilities.Enable Role-Based Access Control (RBAC)
Configure least-privilege access on all components with RBAC (enabled by default since v1.6 but needing granular configuration. Note: upgrade from prior versions requires disabling legacy Attribute-Based Access Control (ABAC).kubectl get clusterrolebinding
or kubectl get rolebinding -all-namespaces
.automountServiceAccountToken
to false for applications that do not need access to the API.Use namespaces to establish security boundaries
Reduce risks of lateral escalation by isolating components by creating separate namespaces. In addition to increasing security, this will facilitate security control when configuring Network Policies. Use kubectl get ns to check for remaining default namespacesSeparate sensitive workloads
Run sensitive workloads on a dedicated set of machines to reduce the risk of a breach through a less-secure application sharing a container runtime or host.Prevent exposure of sensitive information through metadata
Unrestricted access to information recorded in metadata, statistical reports, search indices, or other resources might be leveraged to extract original information or intuit some details.Create and define cluster network policies
Leverage Network Policies to control network access into and out of your containerized applications. When using a managed Kubernetes provider, ensure compatibility with their Network Policies and configure them granularly to eliminate unwanted default options.Run a cluster-wide Pod Security Policy
Configure Pod Security Policy admission controller to replace default values with least privileged access values to define how workloads are allowed to run in your cluster. Consider defining a policy and enabling the Pod Security Policy admission controller.Harden node security
To improve your nodes security posture:Turn on audit logging
Enable audit logs and check them for suspicious API calls.Get in touch with Cisco Cloud Native Security Solution to secure your Kubernetes API and RBAC links.