×

Kubernetes API Security – The Challenges & Best Practices

Application-experience
Alexei Kravtsov

Sunday, February 21st, 2021

3 min read

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.

CVE-2020-8559n Challenge to Kubernetes 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:

  • Allowing attackers to intercept certain requests to the Kubelet, where they can cause the client to follow a redirect response. The client then, uses the credentials from the original request leading to other nodes being compromised.
  • Even if TLS for all API traffic was configured correctly, these allowed attackers to:
  • Inject malicious code into containers to access secrets, exfiltrate data, mine for cryptocurrencies, or more
  • Crash the entire cluster

In short, CVE-2020-8559n basically enabled any successful attacker to take full control of the targeted application.

9 Kubernetes API Security best practices

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.

  1. 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.
  2. 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).
  • Favor namespace-specific permission over cluster-wide permissions
  • Use kubectl get clusterrolebinding or kubectl get rolebinding -all-namespaces.
  • When granting access to the Kubernetes API, create service accounts individually with the narrowest possible set of permissions needed at each use site.
  • Set automountServiceAccountToken to false for applications that do not need access to the API.
  1. 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 namespaces
  2. Separate 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.
  3. 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.
  4. 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.
  5. 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.
  6. Harden node security To improve your nodes security posture:
  • Check your host configuration against CIS Benchmarks.
  • Secure Network Access to sensitive ports: block access from kubelet ports and limit access to Kubernetes API exclusively to trusted networks.
  • Restrict admin access to Kubernetes nodes.
  1. 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.

© 2023 Cisco Systems, Inc.