0% found this document useful (0 votes)
139 views6 pages

Kubernetes Security Essentials: The Kubernetes Attack Surface

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
139 views6 pages

Kubernetes Security Essentials: The Kubernetes Attack Surface

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

BROUGHT TO YOU IN PARTNERSHIP WITH

Kubernetes
CONTENTS

∙ The Kubernetes Attack Surface

∙ Securing the Software Supply Chain

Security Essentials ∙ Securing Kubernetes Infrastructure

∙ Securing Deployed and Running


Workloads

∙ Conclusion

WEI LIEN DANG


CO-FOUNDER & CHIEF STRATEGY OFFICER, STACKROX

By every measure, today Kubernetes is the de facto standard for THE KUBERNETES ATTACK SURFACE
automating the deployment and management of cloud-native To understand how to protect a Kubernetes environment, it is
applications. Its adoption is transforming the ways in which informative to understand its relevant attack surface. The attack
organizations of every size, in every industry, develop and release surface within a Kubernetes cluster consists of three main areas that
software using technologies such as containers, microservices, must be protected:
and declarative APIs. In parallel, these new technologies and
1. The software supply chain for building the immutable
architectures give rise to broad security risks and challenges that artifacts used to deploy and run containers
organizations must protect against. Kubernetes introduces a new
2. Infrastructure components that must be provisioned and
threat environment — one that is as dynamic, fast-moving, and
configured to run Kubernetes
active as containerized applications themselves.
3. Deployed and running containers that make up individual
Kubernetes, with its breadth of cluster components and associated Kubernetes applications

tooling, also introduces complexity for an organization’s end


Nearly all Kubernetes threat vectors can be mapped to one of these
users. It requires teams to learn new skills and adopt new security
three categories. This Refcard uses them as a framework to describe
workflows across development and operations. This complexity
key security concepts that comprehensively span Kubernetes
can expose organizations to a potentially expansive set of attack
infrastructure and applications.
vectors throughout Kubernetes environments that stem from
vulnerabilities, misconfigurations, or other operational issues.

As Kubernetes increasingly becomes a foundational infrastructure


platform that underpins modern software delivery, securing
it becomes critical. The broader Kubernetes community has
undertaken several efforts to increase security awareness, including
conducting a security audit of the Kubernetes platform, publishing
a Kubernetes attack matrix based on the MITRE ATT&CK framework,
publishing a security whitepaper on best practices, and establishing
industry-standard security benchmarks.

These efforts can help development, operations, and security leaders


develop effective strategies for implementing new security measures
to protect their Kubernetes environments.

1
Continuous Security for
Cloud-Native Applications

First Kubernetes-native security platform that enables organizations to


securely build, deploy, and run cloud-native applications anywhere.

Lower Operational Cost Reduce Operational Risk Increase Developer Productivity

DevOps and Security teams can use a Ensure alignment between security and Leverage Kubernetes to seamlessly
common language and source of truth infrastructure to reduce application provide guardrails supporting developer
downtime velocity

Secure Supply Chain Secure Infrastructure Secure Workloads

Standardize on Kubernetes as your Leverage native controls for built-in Accelerate your pace of innovation while
common platform for declarative and security that works with Kubernetes, ensuring your applications comply with
continuous security not against it security policies

Contact us today to get started


stackrox.com
Trusted by
REFCARD | KUBERNETES SECURITY ESSENTIALS

1. SECURING THE SOFTWARE Secrets should not be embedded in images since anyone with access

SUPPLY CHAIN to the image — either by downloading it from a registry or once it

In Kubernetes environments, the software supply chain acts as a is built — would be able to view them in cleartext, and because it

centralized place to make any software changes for propagation into provides unnecessary exposure prior to when the secret needs to be

production environments. It also serves as a chokepoint where users used. In Kubernetes clusters, you can use Kubernetes secrets to pass

can incorporate security measures that have an outsized impact on this sensitive data to pods.

the rest of the application lifecycle.


IMAGE SCANNING
Container images constitute the standard application delivery format Once images are built, they must be scanned to avoid introducing
in Kubernetes environments. Building these images is the primary vulnerabilities into your running Kubernetes clusters. Image scanners
goal of a cloud-native software supply chain, so securing the supply are available as standalone tools or in some cases, are integrated
chain should primarily focus on image security. The wide distribution with image registries. It is critical to utilize an image scanner with
and deployment of these container images require a well-thought- several or all of the capabilities listed here:
out strategy for ensuring their security.
SECURITY AREAS SCANNER CAPABILITIES
Figure 1: Software supply chain
• Installed OS packages • Per-layer scanning

• Installed runtime libraries • Binary fingerprinting


• Secrets or other • File contents testing
sensitive data • Open-source license checking

VULNERABILITY TYPES VIOLATION TYPES

• Database secret embedded in image


• OS-level vulnerabilities • Critical severity base image
• Programming language- vulnerabilities
BASE IMAGES
specific vulnerabilities • Library with unwanted license
Security of your container images often starts with your base type used
operating system (OS) images. Whether you build a base image from
scratch or use a third-party one, trust is critical. Consider criteria Image scanning should be a requirement for passing image builds.
such as the provider (known company or open-source community), Results can be used to implement policies that determine whether a
its availability on a reputable image registry, and the accessibility of build should pass or fail based on the number, severity, and type of
source code for all image components. Base images that are used vulnerabilities detected in a given image.
should also be updated frequently to address any newly disclosed
vulnerabilities or other security concerns. BUILD SYSTEMS
The infrastructure, namely build and CI systems and pipelines, used
IMAGE COMPONENTS to create these images must also be secured. Below are essential
Any container images that are built should be kept as minimal as security measures to take:
possible. Ideally, they should include only the binaries, libraries, and • Limit administrative access to the build infrastructure
configuration files necessary for the containerized application to • Allow only required network ingress
run so as to avoid additional avenues of exploit. In particular, the
• Manage any necessary secrets carefully, granting only
following should be avoided in production environments whenever minimal required permissions
possible:
• Use network firewalls to allow access only from trusted sites
used to retrieve source or other files
IMAGE CONTENTS EXAMPLES

Package managers apt, yum, apk CONTAINER REGISTRY


Once an image has been built, it must also be stored securely in an
Network tools and clients wget, curl, netcat, ssh
appropriate image registry. A private, internal registry can provide
Unix shells sh, bash
greater security but imposes the added operational overhead of
TLS certificate keys, cloud provider managing registry infrastructure and relevant access controls. An
Secrets credentials, SSH private keys, database alternative is to use a registry managed by a cloud platform or other
passwords
provider.

3 BROUGHT TO YOU IN PARTNERSHIP WITH


REFCARD | KUBERNETES SECURITY ESSENTIALS

2. SECURING KUBERNETES They can be categorized as:

INFRASTRUCTURE • Control plane components – manage operations


Kubernetes is the critical foundation for how cloud-native throughout the cluster.
applications are deployed and managed. Therefore, security
• Worker node components – run containerized
measures to protect the components that make up Kubernetes
applications in pods.
itself, including remediating vulnerabilities or preventing
misconfigurations, is essential to protecting your clusters. Every The Kubernetes control plane makes global decisions regarding
Kubernetes cluster contains a set of infrastructure components a cluster’s operations. As a result, guarding against threats to its
needed to run the platform and applications on it. These components is paramount since these could lead to the entire cluster
components may require administrator or user configuration when environment being compromised. The two tables below list the
provisioning clusters and understanding them can help focus efforts control plane and worker node components with corresponding
on valuable security mitigations. threat vectors and security measures to implement.

CONTROL PLANE COMPONENTS


COMPONENT DESCRIPTION EXAMPLE THREAT VECTORS SECURITY MEASURES

• Core control plane component that • Upgrade to recent version or apply


handles API requests to manage the available patches
state of cluster resource objects • Privilege escalation vulnerabilities that
allow access to cluster-wide resources • Restrict access to Kubernetes API
• Primary interface that control plane by ensuring client authentication,
kube-apiserver
and worker node components, • Denial-of-Service (DoS) attacks based configuring RBAC authorization,
workloads, and Kubernetes clients on using manipulated YAML files and encrypting API traffic
communicate with for ongoing
operations • Turn on audit logging

• Encrypt sensitive information


Distributed key-value store that
(e.g., secrets in etcd)
Kubernetes clusters use to store all Access allows exposure of full details,
etcd their data, including data about their including critical and sensitive operational
• Apply strong authentication and
resources, configurations, metadata, data, about cluster environments
access control; limit read/write
and overall state permissions on data

Handles pod scheduling and placement Compromise can lead to scheduling of • Restrict permissions on pod
across available worker nodes in clusters new pods or placement that increases specifications and apply RBAC
kube-scheduler by considering several parameters (e.g., risk to critical applications (non-sensitive to apply minimum privileges
available resources, affinity and anti- and sensitive workloads running on the
affinity rules, taints and tolerations) same node) • Configure to only serve HTTPS

kube-controller- Manages the state of resources including


manager nodes, pod replicas, and services • Restrict permissions on pod
Privilege escalation on control loops can specifications and apply RBAC
occur when individual service account to apply minimum privileges
Relevant for load balancing, node credentials for each controller are not used
cloud-controller- termination, and routing in cloud provider • Configure to only serve HTTPS
manager environments

4 BROUGHT TO YOU IN PARTNERSHIP WITH


REFCARD | KUBERNETES SECURITY ESSENTIALS

WORKER NODE COMPONENTS


COMPONENT DESCRIPTION EXAMPLE THREAT VECTORS SECURITY MEASURES

Primary node agent that manages • Access to the kubelet is unauthenticated • Upgrade to latest version or apply
individual containers running in by default available patches
kubelet
pods and their state based on pod • Its API endpoints can be used to gain additional • Ensure strong authentication and
specifications access and privileges on nodes and pods authorization

Forwards traffic addressed to virtual


• Several of its operating modes enable cluster
IP addresses of Kubernetes services
services to be exposed externally Restrict permissions on the
kube-proxy and corresponding pods; serves as a
• May use relevant kubeconfig file without kubeconfig file
network proxy that applies network
rules and protocols (e.g., TCP, UDP) permissions

• Upgrade to the latest version


Manages and executes containers
Interfaces with kernel for multiple system-level
Container that deploy and run on individual • Harden nodes using Linux security modules
functions, so compromise or container breakouts
runtime nodes; handles functions that • Apply strong access controls regarding who
can result in risks to the underlying node
require interfacing with kernel can control the container runtime

3. SECURING DEPLOYED AND SECURITY CONTEXTS


The main Kubernetes controls that allow pod restrictions to be
RUNNING WORKLOADS
applied at runtime are referred to as security contexts. They form an
Once the software supply chain (including the images that are
important aspect of how pod runtime security works in Kubernetes.
built using it) and Kubernetes cluster infrastructure are adequately
secured, the remaining focus is on security controls for the
WHAT THEY ARE WHAT THEY DO EXAMPLE
Kubernetes pods that are deployed and run. Pods are the smallest
units deployed into clusters and collectively form Kubernetes Setting security Whether pods run
Restrictions on
applications, so they are ultimately the targets subject to individual contexts helps further privileged, their
individual running
harden pods and make filesystems are read-
exploits. Securing pods and their containers requires substantial pods; these
them less exposed only if they use Linux
settings can be
attention — doing so enables more granular security controls that to compromise; they security modules such
included in pod
better scope to requirements of individual application components. can also be scoped to as seccomp and other
manifests
individual containers. system-level capabilities.

Deploy-time and runtime security involve separate security measures


but are related in that they should primarily focus on first setting
KUBERNETES NETWORK POLICIES
parameters that restrict what containerized applications can do,
Additionally, network segmentation of pod-to-pod traffic is another
and then subsequently monitor for any deviations (or attempts to
substantial security measure that is required to ensure Kubernetes
deviate) from those restrictions.
applications are adequately protected. It limits the impact of
an attacker that is able to gain access to any particular group of
ADMISSION CONTROLLERS
deployed and running containers, including restricting the ability to
The primary mechanisms for restricting deployment of pods in
laterally move throughout a cluster.
Kubernetes are called admission controllers.

WHAT THEY ARE WHAT THEY DO EXAMPLE


WHAT THEY ARE WHAT THEY DO EXAMPLE

Specify pod Pod Security Policy (PSP) Configure ingress and Apply a “default-deny-
requirements uses an admission controller egress traffic to and all” network policy that
A group of plugins Policies that from your applications isolates all pods; once in
before they can to set restrictions (limited
that govern and enable network by restricting pod-to- place, network policies
be deployed into to a subset of fields in
enforce what is isolation between pod traffic; requires a to enable Internet
a cluster; prevent pod manifests); they can
allowed to run pods network plugin that access and pod-to-pod
pods that don't be augmented by custom
within a cluster actually enforces traffic can be added as
meet the conditions validating admission
from deploying controllers. Network Policies needed.

5 BROUGHT TO YOU IN PARTNERSHIP WITH


REFCARD | KUBERNETES SECURITY ESSENTIALS

RUNTIME THREAT DETECTION


Finally, the security concepts outlined above must still be
WRITTEN BY WEI LIEN DANG,
complemented with runtime threat detection since no security CO-FOUNDER & CHIEF STRATEGY OFFICER,
controls can be considered foolproof. System-level activity such as STACKROX

process execution and network communication can be monitored Wei Lien Dang is Co-Founder and Chief
at the level of individual containers to determine potential Strategy Officer at StackRox. He is responsible
for leading initiatives related to technical evangelism and go-
indicators of compromise. Because containers are designed to be to-market. Previously, he held senior product management
declaratively configured and immutable, deviations from expected roles at Amazon Web Services, Splunk, CoreOS, and Bracket
Computing. Wei Lien holds an MBA with high distinction from
activity that are either anomalous or malicious are far easier to spot Harvard Business School and a BS in applied physics with
and remediate in Kubernetes environments by re-instantiating pods, honors from Caltech.
giving security operators a significant advantage in their analyses
and investigations.

CONCLUSION
Kubernetes is a powerful yet complex system that is rapidly
transforming how organizations build, ship, and run modern software
DZone, a Devada Media Property, is the resource software developers,
applications. Its benefits come with associated security demands that
engineers, and architects turn to time and again to learn new skills, solve
must be addressed to minimize risks and threats to your business. An software development problems, and share their expertise. Every day,
hundreds of thousands of developers come to DZone to read about the latest
effective approach to securing Kubernetes environments is based on technologies, methodologies, and best practices. That makes DZone the ideal
place for developer marketers to build product and brand awareness and
applying controls to secure the following key areas: drive sales. DZone clients include some of the most innovative technology
and tech-enabled companies in the world including Red Hat, Cloud Elements,
• The software supply chain used to build container images Sensu, and Sauce Labs.

• Infrastructure components needed to run Kubernetes


clusters, including its control plane and worker nodes Devada, Inc.
600 Park Offices Drive
• Deployed and running containerized workloads made Suite 150
Research Triangle Park, NC 27709
up of individual pods 888.678.0399 919.678.0300
Copyright © 2020 Devada, Inc. All rights reserved. No part of this publication
By leveraging native security controls in Kubernetes, organizations may be reproduced, stored in a retrieval system, or transmitted, in any form
or by means of electronic, mechanical, photocopying, or otherwise, without
can achieve comprehensive security across these areas and scale prior written permission of the publisher.

their production usage of Kubernetes with confidence.

6 BROUGHT TO YOU IN PARTNERSHIP WITH

You might also like