karat

Kubernetes Authorization Reporting and Alerting Tool

Kubernetes' RBAC authorization model is incredibly powerful and flexible. Granting permissions and priveleges to users, groups, and service accounts is as simple as running a kubectl command or launching a Helm template.

However, this ease of use and flexibilty means unintended permission grants and privilege escalations can creep into your Kubernetes cluster over time. Imagine this scenario: a cluster admin launches an application with a service account that has the ability to view pods across all namespaces in the cluster in the default namespace. Later, they delete that app, but not the service account. A month later, that same admin adds a non-privileged user to the default namespace so that they can launch their app. Now, that non-privileged user can use the service account to view pods throughout the cluster.

karat adresses this problem by surfacing Kubernetes RBAC information in a way that is clear and actionable.

karat can be used in two ways:

1. As a cli that reports on the state of your cluster's RBAC permissions
2. As an http server that reports when undesired permission grants have been created. This can be hooked into an alert system like Prometheus' Alertmanager to ensure your operations team can react in realtime.

Example Usage

Use the cli to see who has admin or escalated privileges in the cluster

$ karat report

The following users, groups, and service account have direct admin access to the cluster
NAME         KIND             GRANTED BY                      NAMESPACE
jsmith       user             clusterRoleBinding:c-12345
dev-group    group            clusterRoleBinding:c-45678
defatult     serviceAccount   clusterRoleBinding:c-98765      kube-system

The following users and groups have indirect admin access to the cluster
NAME         KIND             OBTAINED THROUGH (resource namespace:name)
jdoe         user             serviceAccount default:svcAccount1

The following users, groups, and service accounts have direct elevated (but not full admin) privileges in the cluster:
NAME               KIND             GRANTED BY
network-admins     group            clusterRoleBinding:c-45454
...

Use the cli to take a point-in-time snapshot report of your cluster's permissions and compare it to the cluster's state at a later date

$ karat report snapshot --output-file permissions-4-1-2019.json
Report saved to permissions.json

# At a later date, compare the current state of your cluster to a previous report snapshot

$ karat report diff --input-file permissions-4-1-2019.json

No new users, groups, or service accounts have been granted admin access to the cluster

The following new users, groups, and service accounts have been granted elevated privileges
NAME         KIND             GRANTED BY                    
bmurray      user             clusterRoleBinding:c-12121

Launch karat as an http server and check your cluster's state

$ karat launch-server --listen 0.0.0.0:8080 --config karat-config.yaml
karat listening 0.0.0.0:8080
# karat-config.yaml can outline your cluster's expected auth state and what you wish to alert on

# Status is ok because there are not unexpected privilege escalations
$ curl https://karat-server:8080/status
curl -k -i https://localhost:6443
HTTP/2 200
content-type: application/json

{
  "status": "ok"
}

# Status is "failed" because there are unexpected privilege escalations
$ curl https://karat-server:8080/status
curl -k -i https://localhost:6443
HTTP/2 418
content-type: application/json

{
  "status": "failed"
  // details on the unexpected privileges
}

Using curl is an oversimplication, but hopefully it illustrates how karat can be integrated with an alert manager to let you know when your cluster has been compromised.

Ideas for further development

• Workload reporting and alerting - In clusters with podSecurityPolicies enabled, karat could report and alert on which users can launch privileged container.
• Rancher integration - User and group ids generated by Rancher are opaque and not meaningful to humans. This integration would resolve those ids to the users and groups from your authentication provider.
• Web UI - The HTTP server could also provide a UI that exposes the same reporting functionality available in the cli. It could generate HTML and PDF reports that could be circulated throughout your organization.