This technical deep dive highlights key capabilities released as part of Twistlock 18.11. To learn more about what’s included with Twistlock 18.11, check out our full release blog post.
According to Kubernetes documentation:
“User accounts are for humans. Service accounts are for processes, which run in pods.”
Kubernetes has a rich Role Based Access Control (RBAC) model based around the notion of service and cluster roles. This model is fundamental in securing the entire Kubernetes cluster. These roles are used to control access to resources and services within namespaces and across the cluster. For reference, here is a great KubeCon 2016 presentation by Eric Chiang on Kubernetes Auth and Access Control explaining RBAC in further detail.
While these service accounts can be manually inspected with kubectl, it’s almost impossible to visualize and understand their scope at scale.
Discovery and monitoring for service accounts
Twistlock Radar provides a discovery and monitoring tool for service accounts. Every service account associated with a resource in a cluster can easily be inspected. For each account, Twistlock shows detailed metadata describing the resources it has access to and the level of access it has to each of them. This visualization makes it easy for security staff to understand role configuration, assess the level of access provided to each service account, and mitigate risks associated with overly broad permissions.
How it works
Twistlock inspects every pods’ service account Service and Cluster Roles within your Kubernetes clusters.
For example, let’s look my nginx-ingress-controller. From Radar, the landing page when you authenticate into your Twistlock instance, I can see all the containers, applications, and namespaces that make up my entire environment.
Zooming into the ingress-nginx namespace and clicking on the nginx-ingress-controller icon, I am presented with all the information pertaining to this image and its associated containers, including a notification about a runtime incident! But, this blog is for service accounts, so you can read about Twistlock Runtime Defense here. Note in the top right corner of the information window there is the service account “nginx-ingress-serviceaccount” associated with the pod.
Clicking on the service account name, you are presented with both the service roles and cluster roles for the nginx-ingress-serviceaccount service account:
Clicking on each role will show the resource, verbs and API group within the role binding:
Twistlock will surface this data for any configuration of Kubernetes you may be using at your organization — OpenShift, EKS, PKS, you name it! In the example below, I included an OpenShift service account.
Now, let’s gather that from kubectl:
- List all your Service Accounts across namespaces and across clusters!
$ kubectl get sa –all-namespaces
- Enumerate through all the rolebinding and clusterrolebindings across namespaces and across clusters:
$ kubectl describe rolebinding nginx-ingress-role-nisa-binding -n ingress-nginx
$ kubectl describe clusterrolebinding nginx-ingress-clusterrole-nisa-binding -n ingress-nginx
- Put it all together and present in an understandable, manageable format.
Getting Kubernetes RBAC configuration right is a major concern for cluster administrators as it affects the cluster security. With our latest feature, we hope to enable customers to better monitor the privileges of service accounts across their Kubernetes clusters.
Visibility into your microservices environment is critical to its security and well being. Our goal at Twistlock is to provide these capabilities and knowledge.
Learn more about Kubernetes service account monitoring
To learn more about Kubernetes service account monitoring, watch this video conversation from the Cloud Native Security Podcast with Twistlock Director of Evangelism Sonya Koptyev and Solutions Architect Neil Carpenter.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.