📌 This operator is actively maintained and used in production. If you don't see frequent updates, it means the operator is stable and just works! I am quick to respond to any issues that arise.
The kubeconfig operator implements a Kubeconfig custom resource that specifies a set of RBAC permissions. Based on those permissions it creates a correspnding kubeconfig file which it stores in a secret.
The following example creates a kubeconfig limited to
- read access for namespaces
- read access for configmaps in namespace: kube-system
- read/write access for configmaps in namespace: default
Install the newest operator version or a specific version:
kubectl apply -f https://raw.githubusercontent.com/klaudworks/kubeconfig-operator/main/manifests/bundles/install.yamlor install a specific version:
kubectl apply -f https://raw.githubusercontent.com/klaudworks/kubeconfig-operator/v1.3.2/manifests/bundles/install.yamlThen, apply the following sample Kubeconfig by executing the following command:
cat <<EOF | kubectl apply -f -
apiVersion: klaud.works/v1alpha1
kind: Kubeconfig
metadata:
name: restricted-access
spec:
clusterName: local-kind-cluster
# specify external endpoint to your kubernetes API.
# You can copy this from your other kubeconfig.
server: https://127.0.0.1:52856
expirationTTL: 365d
clusterPermissions:
rules:
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- watch
namespacedPermissions:
- namespace: default
rules:
- apiGroups:
- ""
resources:
- configmaps
verbs:
- '*'
- namespace: kube-system
rules:
- apiGroups:
- ""
resources:
- configmaps
verbs:
- get
- list
- watch
EOFAfter applying the Kubeconfig custom resource, you can view it's issue, expiration and refresh timestamp.
kubectl get kubeconfigs -AExtract and store the actual kubeconfig yaml file from the secret that is created:
kubectl get secret restricted-access -o jsonpath="{.data.kubeconfig}" | base64 --decode > restricted-access-kubeconfig.yaml- What do I use this for?
- limit access for different users e.g. to a dev namespace
- protect yourself (and others) from accidentally performing destructive actions by using a restricted (e.g. readonly) Kubeconfig for day to day operations.
- How to revoke a Kubeconfig?
- just delete the Kubeconfig resource from the cluster and the service account that grants permissions will be cleaned up.
- When will the Kubeconfig be refreshed?
- the current setting is that the kubeconfig in the secret is refreshed after 80% of it's validity passes. I.e. if the expirationTTL is set as 100 days, the kubeconfig expires after 80 days.
- What happens when a Kubeconfig expires?
- you will not be able to use it anymore and have to copy the new kubeconfig from the secret.
- Can I change the permissions?
- yes, you can change the permissions for a Kubeconfig at any time.
- Can I change the expirationTTL?
- no, currently you have to delete and recreate the Kubeconfig resource to update the expirationTTL.
- Clone the repository:
git clone github.com:klaudworks/kubeconfig-operator.git - Ensure you install kind or you have another Kubernetes distribution installed.
- Install the CRDs
kubectl apply -f manifests/crd
- Create the namespace for the controller
kubectl create namespace kubeconfig-operator
- Test the controller with the
Kubeconfigyaml manifest from above. - Run the actual controller locally via:
go run cmd/main.go --kubeconfig ~/.kube/kind.yaml --kubecontext kind-kind - Download the kubeconfig
kubectl get secret restricted-access-kubeconfig -o jsonpath="{.data.kubeconfig}" | base64 --decode
This operator is based on Achilles SDK developed by reddit. It allows us to specify the operator's behavior as a finite state machine.

