If you are working with Kubernetes a lot, you have probably built several basic clusters for learning purposes. You probably don’t have integration set up with an external system to authenticate users for your basic clusters. To try out many of the security-related concepts in your clusters, you will need to add Kubernetes users that are not cluster administrators. This blog post will show you how to create new Kubernetes users in your clusters.
Kubernetes Pod Security Policy allows you to control the security specifications pods must adhere to in order to run in your cluster. You can block users from deploying inherently insecure pods either intentionally or unintentionally. This sounds like a great feature and a security best practice, and can be a big step toward keeping your cluster free of insecure resources.
This is part two of a two-part blog about internal DNS resolution and network access for Pods in Kubernetes. In part one we looked at how internal DNS services are configured in Kubernetes and how DNS resolution is configured for containers in Pods for user workloads. In this part, we will look at how network traffic gets from the containers in Pods for user workloads to the Pods providing DNS functionality.
Service discovery is one of the important benefits of using a container/Pod orchestrator. When you create a Service in Kubernetes, controllers running behind the scenes create an entry in the cluster’s DNS records so that other applications deployed in the cluster can look up the Service using its name. In part one of this blog, we will look at how DNS resolution is set up for containers in Pods.
A couple weeks back I took the test for Certified Kubernetes Application Developer developed by the Cloud Native Computing Foundation (CNCF), in collaboration with The Linux Foundation. For me personally it was satisfying to complete the test and become certified. Today’s blog will be the first in a series to share with you all that …
I ran across a great tool from Walmart Labs called Kubeman. If you are managing multiple Kubernetes clusters, and that’s almost always the case if you’re using Kubernetes, especially with Istio, Kubeman is a tool you need to consider for troubleshooting.
I have been working with a client recently on getting Tomcat access and error logs from Kubernetes pods into Elasticsearch and visible in Kibana. As I started to look at the problem and saw Elastic Stack 7.5.0 released, it also seemed like a good idea to move them up to the latest release. And, now …
In a previous post, What is Container Orchestration?, I explained container orchestration using some examples based on Docker Swarm. While Docker Swarm is undeniably easier to both use and explain, Kubernetes is by far the most prevalent container orchestrator today. So, I’m going to go through the same examples from that previous post but, this time, use Kubernetes. One of the great things about Docker Enterprise is it supports both Swarm and Kubernetes so I didn’t have to change my infrastructure at all.
Helm has been widely publicized as the package manager for Kubernetes. We’ve seen the need over and over for Helm. Unfortunately, Helm 2 requires Tiller and Tiller opens a lot of security questions. In particular, in a multi-user, multi-organization, and/or multi-tenant cluster, securing the Tiller service account (or accounts) was difficult and problematic. As a …
Managing a Kubernetes cluster with one user is easy. Once you go beyond one user, you need to start using Role-Based Access Control (RBAC). But, once you get beyond a couple of users and/or teams and a few namespaces for them, it quickly becomes difficult to keep track of who can do what and where. And, as time goes on and more and more people have a hand in setting up your RBAC, it can get even more confusing. You can and should have your RBAC resource definitions in source control but it’s not easy to read and is hard to visualize. Enter the open source who-can kubectl plugin from the folks at Aqua Security. It gives you the ability to show who (subjects) can do what (verbs) to what (resources) and where (namespaces).