A small operator to automatically generate bcrypt htpasswd files from CRDs. This allows you to handle your htpasswd accounts as Kubernetes resources, and reuse existing secrets stored in kubernetes.
htpasswd-operator features both a setup for an init container and an operator to automatically watch and deploy changes in the CRD. If used as an operator, secrets and configmaps referenced by any htpasswd-user are automatically updated when a change occurs.
If you need multiple operators or want to limit the access or exclude some credentials, you can restrict the access to the users for each operator using Cluster Roles and Service Accounts.
The image is available at DockerHub: mowirth/htpasswd-operator
| Env Variable | Description | Default |
|---|---|---|
| HTPASSWD_FILE | Set the output file. The directory must already exist. | ./htpasswd |
| KUBE_CONFIG | Path to the kube config. Can be empty. | "" |
| PID_FILE | Path to the PID file. Can be empty. | "" |
| LOG_LEVEL | Set Log Level, use TRACE, DEBUG, INFO, WARN, ERROR, FATAL for specific logging | INFO |
An example setup for a docker registry and the operator as an init container can be found in the kubernetes/
directory.
The CRD is available at kubernetes/htpasswd-account.crd.yaml and must be applied prior to creating any users.
The operator requires sufficient permission to list the CRD resources and the secrets and configmaps from where the users should be retrieved.
If one of the referenced secrets or configMaps is removed or updated, the htpasswd entry is removed or updated automatically
The syntax for the htpasswd user is very similar to other deployments. We support mixing configMapValues, secretKeyValues and normal values, so you can directly define your username and load the password from the secret.
---
kind: HtpasswdUser
apiVersion: flanga.io/v1
metadata:
name: htpasswd-admin
spec:
username:
value: admin
password:
value: adminPasswordAdditionally, it is possible to retrieve the user from a configMap:
kind: HtpasswdUser
apiVersion: flanga.io/v1
metadata:
name: htpasswd-configuser
spec:
username:
configMapKeyRef:
name: htpasswd-configusers
key: test-username
password:
configMapKeyRef:
name: htpasswd-configusers
key: test-passwordFinally, it is also possible to load your user from a secret:
kind: HtpasswdUser
apiVersion: flanga.io/v1
metadata:
name: htpasswd-testuser1
spec:
username:
secretKeyRef:
name: htpasswd-users
key: test1-username
password:
secretKeyRef:
name: htpasswd-users
key: test1-passwordIf you want to send a SIGHUP signal after regenerating the htpasswd file, you can configure a PIDFile over the config. If a change is written to disk, the operator sends a SIGHUP signal to the process, signaling a reload.
Please note that the reload is debounced by a second to prevent unnecessary restarts during many config changes.
We support running htpasswd-operator as an init-container, standalone and as a watcher.
Compared to the watcher mode, the operator exists abnormally if something fails (or normally when the file was created), where the watch image continues to listen for changes.
< 6A12 div class="markdown-heading" dir="auto">