Kufefe - Ephemeral Kubeconfig Generator

Kufefe lets you generate kubeconfig files that are;

• Ephemeral - because giving out the cluster kubeconfig is dangerous as it never expires
• Scoped - allowing you to limit access to only what is required

It runs inside your cluster and scans for new cluster-scoped Requests. Related resources (the ServiceAccount, Secret and ClusterRoleBinding) are automatically deleted through their ownerReference to the Request. For resources that are namespaced, they will always be created in the deployment namespace.

Kufefe currently supports Kubernetes version 1.25 and up.

Installation

Installation is done via Helm. Only a few values need to be set. Kufefe does not expose a service (and does not need to) - it runs as a single pod and consumes very little in terms of resources.

helm repo add kufefe https://cmdrsharp.github.io/kufefe
helm install kufefe kufefe/kufefe

See values.yaml for a comprehensive list of values that can be set. For many cluster types, you will need to set kufefe.clusterUrl to the API Address of your Kubernetes Cluster.

Request CRD

The Request CRD a simple cluster-scoped resource where you specify which ClusterRole you want the request to be tied to. A request will look something like this:

apiVersion: "kufefe.io/v1"
kind: Request
metadata:
  name: i-need-a-kubeconfig
spec:
  role: my-cluster-role # See note below on roles!

Shortly upon creating this Request, you should see that it is marked Ready.

❯ kubectl get req
NAME                  READY   AGE
i-need-a-kubeconfig   true    2s

You can now get the kubeconfig:

❯ kubectl get req i-need-a-kubeconfig -o=jsonpath='{.status.kubeconfig}'

Privilege Escalation & Role Aggregation

Kufefe's own RBAC is set up using aggregated cluster roles with the label rbac.authorization.k8s.io/aggregate-kufefe: "true".

In order for Kufefe to be allowed to create Service Accounts that bind to other roles, there are two prerequisites:

1. The role must be annotated with kufefe.io/role: "true". If it is not, Kufefe will not create an SA bound to that role.
2. Kufefe itself must be allowed to bind to the role it is trying to create an SA for. This a Kubernetes mechanism to prevent privilege escalation.

For scenario two, let's say you have a ClusterRole called debug. In order for Kufefe to be allowed to create SA's bound to this role, you would create a ClusterRole like this:

---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kufefe:rbac:bind:debug
  labels:
    rbac.authorization.k8s.io/aggregate-kufefe: "true"
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  resourceNames: ["debug"] # Leave out to allow binding to ANY ClusterRole. Not recommended.

With this role created, Kufefe will now be allowed to create the ServiceAccount tied to the debug role.