This project introduces a mutating webhook for FluxCD Kustomization, designed to extend the functionality of postBuild substitutions beyond the scope of a single namespace. It allows for the use of global configuration variables stored in a central namespace, thus avoiding the need for recursive Kustomize patches or duplicated secrets across multiple namespaces.
In standard FluxCD setups, postBuild substitutions in Kustomizations can only reference secrets within the same namespace. This limitation can lead to redundancy and complexity, particularly in environments requiring consistent configuration across multiple namespaces. This mutating webhook addresses this challenge by enabling global configuration management, significantly simplifying the process.
The webhook listens for Kustomization resources creation or update events. On intercepting such an event, it dynamically injects substitution variables into the Kustomization resource. These variables are fetched from a centralized ConfigMap, allowing for consistent and centralized management of configurations used across various namespaces.
The Kustomize Mutating Webhook is pre-configured to mount the configmap called cluster-config
however, this can be set to any name. Ensure this exists in the cluster otherwise there will be no values to patch into your FluxCD Kustomization resources. Also see Changing ConfigMap Reference
Additionally, the following are required:
- A Kubernetes Cluster with FluxCD installed
- Access (RBAC) to install a Kubernetes Mutating Webhook
Using Kubernetes Manifests
- Clone the Repository
git clone https://github.com/xunholy/fluxcd-kustomize-mutating-webhook.git
cd fluxcd-kustomize-mutating-webhook
- Apply the Kubernetes Manifests
This will set up the mutating webhook in your cluster.
kubectl apply -k kubernetes/static
- Verify Installation
Check if the webhook service and deployment are running correctly.
kubectl get pods --selector=app=kustomize-mutating-webhook -n flux-system
The log level of the webhook can be adjusted to control the verbosity of the logs. This is useful for debugging or reducing the amount of log output in a production environment.
- Update the Log Level Environment Variable
The log level is controlled by the LOG_LEVEL environment variable within the webhook's deployment. To change it, edit the deployment and set the LOG_LEVEL environment variable to one of the following: debug
, info
, warn
, error
, fatal
, or panic
.
Example:
env:
- name: LOG_LEVEL
value: "debug"
- Apply the Changes
After editing the deployment, apply the changes to your cluster:
kubectl apply -k kubernetes/static
- Verify the Changes
Check the logs of the webhook to ensure that the log level has changed:
kubectl logs --selector=app=kustomize-mutating-webhook -n flux-system
The webhook is designed to fetch substitution variables from a specified ConfigMap. To change the ConfigMap it references:
- Update the ConfigMap Kubernetes Deployment
Example:
volumes:
- name: cluster-config
configMap:
name: cluster-config
Note: Only changing the volumes.[0].name.configMap.name
is required.
- Apply the changes to the Deployment.
kubectl apply -k kubernetes/static
- Verify the Changes
You can verify the correct values are being collected by either using the debug
log level which outputs the values on start-up, alternatively you may also verify by inspecting a Kustomization resource that has been mutated.
Distributed under the Apache 2.0 License. See LICENSE for more information.