It is new version of Kerberos Operator, but this time completely written in Scala with Cats-Effects.
This operator deployes KDC, Kadmin servers and creates principals and their keytabs as Kubernetes secrets. Developed using Kubernetes-Client Scala library.
See arcticle for more details: https://novakov-alexey.github.io/k8s-operator/
Why should I use this Operator?
-
Your SPNEGO authentication requires keytab mounted to a Pod: deploy this operator with required principals to get automatically created secrets with keytabs inside
-
Rapid application development having KDC running inside the K8s cluster: deploy this operator and use automatically created service to call KDC or Kadmin servers
-
Principals and keytabs management using K8s custom resources: deploy this operator using Krb resource with required list of principals, and their predefined or random passwords
- kubectl CLI
- dhall CLI
Define namespac,e which will be used to install Kerberos Operator, as environment variable:
export NAMESPACE=<put desired namespace>
# install RBAC
wget -O- -q https://raw.githubusercontent.com/novakov-alexey/krb-operator2/master/manifest/rbac.dhall | \
dhall-to-yaml | kubectl create -n ${NAMESPACE} -f -
# install operator
wget -O- -q https://raw.githubusercontent.com/novakov-alexey/krb-operator2/master/manifest/kube-deployment.dhall | \
dhall-to-yaml | kubectl create -n ${NAMESPACE} -f -
Alternatively, just clone this repository and run make install
in root folder of the repository.
Run make uninstall
to uninstall Kerberos Operator.
wget -O- -q https://raw.githubusercontent.com/novakov-alexey/krb-operator2/master/manifest/rbac.dhall | \
NAMESPACE=${NAMESPACE} dhall-to-yaml | kubectl delete -n ${NAMESPACE} -f -
wget -O- -q https://raw.githubusercontent.com/novakov-alexey/krb-operator2/master/manifest/kube-deployment.dhall | \
NAMESPACE=${NAMESPACE} dhall-to-yaml | kubectl delete -n ${NAMESPACE} -f -
kubectl delete crd krbservers.krb-operator.novakov-alexey.github.io
kubectl delete crd principalss.krb-operator.novakov-alexey.github.io
Below resource creates:
KDC
andKadmin
servers running as two separate containers running in a single Pod
apiVersion: krb-operator.novakov-alexey.github.io/v1
kind: KrbServer
metadata:
name: my-krb
namespace: test
spec:
realm: EXAMPLE.COM
realm
- Kerberos realm where all principals will be created
Below resource creates:
- Principals and their keytabs based on the principal list
apiVersion: krb-operator.novakov-alexey.github.io/v1
kind: Principals
metadata:
name: my-krb1
namespace: test
labels:
krb-operator.novakov-alexey.github.io/server: my-krb # reference to KrbServer
spec:
list:
- name: client1
password:
type: static
value: mypass
keytab: cluster.keytab
secret:
type: Keytab
name: cluster-keytab
- name: user2
keytab: cluster.keytab
secret:
type: KeytabAndPassword
name: cluster-keytab
list
- array of principals
Principal has the following properties:
-
name
- principal name without realm in it. Realm will be added automatically using value ofspec.realm
property -
password
- a property with two different types.static
: with password in the value field.random
: operator generates random password. it does not require password property in the resource at all.Missing password property or default value is
random
. -
keytab
- it is key in the secret object. Secret can have more than one data keys, i.e. more than one keytab files -
secret
- a property with two different types.Keytab
- create keytab as K8s Secret,name
is the Secret name.KeytabAndPassword
- create keytab with separate password entry as K8s Secret,name
is the Secret name,principal[i].name
is a key of a secret for principal passwordK8s secret name. Every principal in the array can have its own secret name, so that multiple secrets will be created
If you apply above two custom resources as is, then it will produce the following objects
in the metadata.namespace, i.e. test
namespace:
Containing Kerberos keytab as secret data:
kubectl describe secret cluster-keytab -n test
Name: cluster-keytab
Namespace: test
Labels: app=krb
Annotations: <none>
Type: opaque
Data
====
cluster.keytab: 274 bytes
user2: 10 bytes
Property principals.secret
in the Krb
spec can be different, so that it will lead to multiple/different
secrets created by the Kerberos Operator.
A Service for KDC, kadmin, kpasswd with their TCP/UDP ports:
my-krb ClusterIP 172.30.37.134 <none> 88/TCP,88/UDP,464/UDP,749/UDP,749/TCP
Krb Pod for KDC
, kadmin
, kpasswd
servers is deployed with two containers:
kubectl get pod my-krb-1-gk52x -n test
NAME READY STATUS RESTARTS AGE
my-krb-1-gk52x 2/2 Running 0 24m
Krb Pod is deployed as Deployment resource:
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/my-krb 1/1 1 1 26s
Examples:
kubectl create -f examples/my-krb-1.yaml
# or
kubectl apply -f examples/my-krb-1.yaml
A create
or update
resource event are handled in the same way. They will create:
-
Deployment, Service, Pod, if some of them is missing
-
Kerberos principal, if its
spec.list[i].secret
is missing. Changes in values other thansecret
are ignored (current limitation). In order to add new principal to thespec.principals
either put new/not-existingsecret
name and desired new principal name. Otherwise, delete Krb resource and create new one with the desiredprincipals
.
A delete
event deletes all objects created by the create
or apply
events: Deployment, Service, Pod and Secrets(s)
kubectl delete -f examples/my-krb-1.yaml
sbt docker:publishLocal
Then use your built image in manifest/*-deployment.dhall
file for krb-operator
container.