Beginning with Kubernetes Hacking into - Part 1
Beginning
with Kubernetes Hacking into - Part 1
Introduction:
Hi
Readers, the world of virtualization is still in a starting stage and combined
with the flavor of security, it’s a very interesting thing to learn and work
with. As first part of the series we will focus on a very new concept of
Virtualization which centers on Kubernetes.
Let’s
start from the very basics. Kubernetes is a powerful open
source tool developed by Google. It helps us to utilize “micro-services” or
better say “containerized” applications across distributed cluster of “nodes”.
The beauty of Kubernetes lies in its highly
resilient infrastructure with almost zero downtime apart from its immense
deployment capabilities as well as offering a host of other features along with
it.
In a nutshell, the main objective of Kubernetes is
to obscure the complexity of managing multiple containers by introducing REST based
Web services in its backend. Kubernetes’s portability factor is another add-on.
You can run it across cross platforms such as AWS, Azure and Apache etc.
Anatomy of kubernetes:
Kubernetes as most others
follows a client-server model. It can be highly customized as per our
requirements though in a simple setup it has a sole master server which works as the controlling node for the entire
setup.
In order to have the basics clear before we would
go around probing its various components in terms of security let us iterate
through the various components in it.
A kubernetes server has :
·
Kube-apiserver:
o
This is one of the most
fundamental aspect acting as the central management entity which receives all
REST service requests for processing to pods, services, replication
sets/controllers etc. This also serves as frontend to the cluster apart from
communicating with the etcd cluster to ensure data storage in etcd is in sync
as per connected details in deployed pods.
·
etcd storage:
o
etcd can be simply termed as a
distributed key value storage holding all the Kubernetes cluster data including
number of pods, their state, namespace, API objects as well as service
discovery details.
Its inherent security feature
allows access only via the API server.
Kube-controller-manager:
o
This manager component helps run
distinct controller processes in the background like number of replicas in a
pod, endpoints controller, populating services and pods which helps regulate
the shared state of the cluster and perform routine tasks. It can be thought as
a change management tool helping spot the changes and working towards the new
desired state.
·
Cloud-controller-manager:
o
This component is responsible
for managing controller processes with dependencies on the underlying cloud
provider including performing checks for termination of nodes, load balancers
or volumes in the cloud infrastructure
·
Kube-scheduler:
o
Kube-scheduler helps
scheduling the pods by reading the service’s operational requirements and
schedules it on the best fit node.
·
A DNS server for Kubernetes
services.
Further to that, the Node components also include
kubelet and kube-proxy on top of “Dockers”.
A neat architecture which would help to visualize
the same goes here:
This is a typical diagram having one master and two
worker nodes
·
Kubelet:
o
A prime component of node
which regularly takes in new or modified pod specifications (primarily through
the kube- apiserver) and ensuring that pods and their containers are healthy
and running in the desired state. This component also reports to the master on
the health of the host where it is running
o
A proxy service which runs on
each worker node dealing with individual host sub-netting and exposing services
to the external world. It is also responsible for forwarding requests to the
correct pods/containers across the various isolated networks in a cluster
·
Kubectl
o
A command line tool that
interacts with kube- apiserver and regulates sending commands to the master
node. Each command is converted into an subsequent API call
Having now obtained an understanding for
kubernetes, let’s take a quick look on the final few terminologies:
·
Pod – Containers
which are to be controlled as a single application working as an encapsulation
for application containers.
·
Service – A set of logical set of pods
and acts as a gateway, allowing pods to send requests to the service without
needing to keep track of physical pods
·
Volume – Works
on a whole pod and is mounted on all containers in the pod. It helps data is preserved
across container restarts.
·
Namespace – A virtual
cluster intended for environments with many users spread across multiple teams
or projects, for isolation of concerns. Resources inside a namespace must be
unique and cannot access resources in a different namespace. Also, a namespace
can be allocated a resource
quota to avoid consuming more
than its share of the physical cluster’s overall resources.
·
Deployment – The desired
state of a pod or a replica set, in a .yaml file. The deployment controller
then gradually updates the environment until the current state matches the
desired state specified in the deployment file.
Since we are now all set having the fundamentals
clear let’s proceed to understand the blend of security with respect to
kubernetes.
Security Implementations in Kubernetes:
Kubernetes offers security at
multiple levels: Clusters, Applications and network.
In terms of end point
security, the APIs are secured through transport layer security (TLS). Authenticated
users only can execute operations on the cluster via APIs
Sensitive information such as
passwords are stored per cluster.
What are the kind of security testing which can be performed/ executed
on kubernetes?
Finding connections on the
internet!
1.
Locating Vulnerable Management
Interfaces
Finding open management
interfaces/dashboards is as easy as querying Shodan/Censys for: KubernetesDashboard,
Kubernetes-master,Kubernetes,Kube
2. Searching for open ports on 10250 and 2379 TCP
3.
The Https service on 10250/TCP
is the default management API interface for Kubernetes clusters. It is not secured
by default!
This means that the developer/administrator
is responsible for securing their services.
4.
As as attack vector by abusing
the API we can achieve low level command execution.
5.
2379/TCP Etcd Port: The
HTTP service on 2379/TCP is the default etcd service for your Kubernets
instance. The API interface is accessible and not secured by default!
6.
A command with : http://<kuberenets
IP>:2379/v2/keys/?recursive=true.
It’ll leak internal passwords,
AWS keys, certificates, private keys, encryption keys among other aspects.
Some of the prime control
points in order to secure your kubernetes environment would involve:
–
Role Based Access Controls
–
Making sure to maintain
privilege security using non-root containers
–
Implementation of Secure CI/CD
pipeline into clusters
–
Hardening Security levels of
Pod, masters and nodes
This was it for now! In the
next part, we will learn how to check configuration level settings, perform
security testing of kubernetes and how it can fit into devsecops
Comments
Post a Comment