Search for a command to run...
Kubernetes shines at the orchestration of thousands of containers but the security of these assets is one of the biggest concern of enterprises today
A technology evangelist and entrepreneur passionate about software development using cloud-native technologies. Currently leading a cross-Atlantic team of enthusiasts developing and extending the core of Kubernetes at kaiops.io
No comments yet. Be the first to comment.
In this series, we will go through the common security vulnerabilities of a Kubernetes Environment. We will also list a few remediation techniques along with some implications if overlooked.
The next best thing after serverless is to use Google Cloud Run to deploy microservices on the cloud with a fraction of the cost compared to K8s
Generally, Kubernetes has a steep learning curve, however, if you are dedicated to burning the midnight oil, then it won't break your back.
The different design scenarios for the deployment of the PEGA Platform in a Customer cloud using Kubernetes
As the state of Kubernetes clusters can change over time due to its dynamic nature, it may be necessary to relocate running pods to different nodes.
Implementing CICD for hosting a static website was a complex set of tasks using Cloud Front and S3 until AWS Amplify made it look so easy.
54% of enterprises mentioned Security as their biggest challenge in Kubernetes. Almost 7 out of 10 have limited or lack resources to manage security as Kubernetes has a steep learning curve. Now it is not only the Kubernetes lacking native security scanning ability rather any vulnerability in an application running on the cluster may lead to a bigger threat. Here are a few hacks from the past:
Now that we know that a single container vulnerability may compromise the overall security of the cluster, let us review a few aspects.
A public cluster is one whose Nodes are accessible from the internet, technically they have one or more networks configured with ExternalIP. You can test it using the following command
kubectl get node <node-name> -o jsonpath='{.status.addresses}' | grep ExternalIP
Replace with your node name in the cluster. following the sample output
If any of your nodes have an ExternalIP then it is exposed, which means all your containers/pods running on this node are also exposed to the public. It is highly recommended to keep your nodes private and route the outgoing traffic using a Cloud NAT.
Kubernetes Dashboard is an open-source deployment used to manage and monitor cluster deployments and other objects. It is available on all clusters and can be deployed or installed with a few simple commands. Here is how you can also deploy it on your cluster:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml
Once installed you can proxy it to access it from your remote machine (machine with cluster access) using
kubectl proxy command.
Now you can access your dashboard using the following url: http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/
Note: The kubeconfig authentication method does not support external identity providers or X.509 certificate-based authentication. The UI can only be accessed from the machine where the command is executed. See
kubectl proxy --helpfor more options.
Now, this is your standard access method, if one of your vulnerable (or compromised) containers has the access to your dashboard then the hacker will have access to the whole Kubernetes cluster.
If you are using Prometheus, Grafana, or Splunk, chances are that you are exposing them by using an external load balancer. These and other observability platforms are often used to monitor and prevent performance, security, and other issues in a cluster. Once exposed to public traffic either through an ingress or through a vulnerable (or compromised) container may lead to a brute force attack. A hacker can take control of the whole cluster once getting access to such a platform.
A privileged container is one that has full access to itself and through the reverse shell technique it can also get full control over its encapsulating Node. Full access to a node exposes all the images stored on it and it may lead to access to other nodes in the network exposing all available resource objects on the cluster. Hackers may deploy a cron job or hijack the resources of the nodes without even letting it be noticed from the Kubernetes platform.
In this part, I have just scratched the surface and mentioned some of the most common security vulnerabilities. An attacker can use impact techniques to destroy, abuse, or disrupt the normal behavior of an environment. I will discuss some more security vulnerabilities in my upcoming articles.