Kubernetes permissions are built with role-based access controls (RBAC), which open up potential risks and need to be carefully controlled. To help find these risky permissions, the CyberArk Labs team has written an open source tool called KubiScan, available in GitHub here. KubiScan helps cluster administrators identify permissions that attackers could potentially exploit to compromise the entire cluster. This is helpful in larger environments with lots of containers and permissions to keep track of. KubiScan automates the process of gathering information about risky Roles and Clusterroles, Rolebindings and Clusterrolebindings, users and pods. This helps k8s administers gain more visibility into their environments and reduce security risks.
KubiScan will help you:
- Identify risky Roles and ClusterRoles
- Identify risky RoleBindings and ClusterRoleBindings
- Identify risky Subjects (Users, Groups and ServiceAccounts)
- Identify risky Pods and Containers
- Dump tokens from pods (all or by namespace)
- Get associated RoleBindings and ClusterRoleBindings to Role, ClusterRole or Subject (user, group or service account)
- List Subjects with their specific type (‘User’, ‘Group’ or ‘ServiceAccount’)
- List rules of RoleBinding or ClusterRoleBinding
- Show Pods that have access to secret data through volume or environment variables
- Get bootstrap tokens for the cluster
Visit the labs extensive research blog “Securing Kubernetes Clusters by Eliminating Risky Permissions” for more details on the research and to learn more about KubiScan. Also, be sure to check out some of the extensive research the CyberArk labs team has done on Jenkins, Docker and other exciting topics. Of note on the Jenkins front is “Tripping the Jenkins Main Security Circuit-Breaker: An Inside Look at Two Jenkins Security Vulnerabilities, ” which details the CVE’s CyberArk Lab’s Nimrod Stoler helped CloudBees find. Check out this post on Kubernetes authentication to learn more about the Conjur Kubernetes-native solution that distributes secrets securely through mutual TLS established with SPIFFE-compliant x509 certificates.