Kubernetes Fury OPA
Kubernetes Fury OPA provides policy enforcement at runtime for the Kubernetes Fury Distribution (KFD) using OPA Gatekeeper.
If you are new to KFD please refer to the official documentation on how to get started with KFD.
The Kubernetes API server provides a mechanism to review every request that is made, being object creation, modification, or deletion. To use this mechanism the API server allows us to create a Validating Admission Webhook that, as the name says, will validate every request and let the API server know if the request is allowed or not based on some logic (policy).
Kubernetes Fury OPA module is based on OPA Gatekeeper, a popular open-source Kubernetes-native policy engine with OPA as its core that runs as a Validating Admission Webhook. It allows writing custom constraints (policies) in
rego (a tailor-made language) as Kubernetes objects and enforcing them at runtime.
SIGHUP provides a set of base constraints that could be used both as a starting point to apply constraints to your current workloads or to give you an idea of how to implement new rules matching your requirements.
Fury Kubernetes OPA provides the following packages:
|Gatekeeper Core||Gatekeeper deployment, ready to enforce rules.|
|Gatekeeper Rules||A set of custom rules to get started with policy enforcement.|
|Gatekeeper Monitoring||Metrics, alerts and dashboard for monitoring Gatekeeper.|
|Gatekeeper Policy Manager||Gatekeeper Policy Manager, a simple to use web-ui for Gatekeeper.|
Click on each package name to see its full documentation.
|✅||No known issues|
|✅||No known issues|
|✅||No known issues.|
|✅||No known issues.|
Check the compatibility matrix for additional information on previous releases of the module.
|furyctl||The recommended tool to download and manage KFD modules and their packages. To learn more about |
|kustomize||Packages are customized using |
|KFD Monitoring Module||Expose metrics to Prometheus (optional).|
You can comment out the service monitor in the kustomization.yaml file if you don't want to install the monitoring module.
- List the packages you want to deploy and their version in a
- name: opa/gatekeeper
furyctldocumentation for additional details about
furyctl vendor -Hto download the packages
Inspect the download packages under
kustomization.yamlthat includes the
./vendor/katalog/opa/gatekeeperdirectory as a resource.
Apply the necessary patches. You can find a list of common customization here.
To deploy the packages to your cluster, execute:
kustomize build . | kubectl apply -f -
⚠️ Gatekeeper is deployed by default as a Fail open (also called
Ignoremode) Admission Webhook. Should you decide to change it to
Failmode read carefully the project's documentation on the topic first.
⚠️ If you decide to deploy Gatekeeper to a different namespace than the default
gatekeeper-system, you'll need to patch the file
vwh.ymlto point to the right namespace for the webhook service due to limitations in the
Exempting a namespace
Gatekeeper supports 3 levels of granularity to exempt a namespace from policy enforcement.
- Global exemption at Kubernetes API webhook level: the requests to the API server for the namespace won't be sent to Gatekeeper's webhook.
- Global exemption at Gatekeeper configuration level: requests to the API server for the namespace will be sent to Gatekeeper's webhook, but Gatekepeer will not enforce constraints for the namespace. It is the equivalent of exempting the namespace in all the constraints. Useful when you don't want any of the constraints enforced in a namespace.
- Exemption at constraint level: you can exempt namespaces in the definition of each constraint. Useful when you may want only a subset of all the constraints to be enforced in a namespace.
⚠️ Exempting critical namespaces like
loggingwon't guarantee that the cluster will function properly when Gatekeeper webhook is in
For more details on how to implement the exemption, please refer to the official Gatekeeper documentation site.
Disable one of the default constraints by creating the following kustomize patch:
kind: K8sUniqueIngressHost # replace with the kind of the constraint you want to disable
name: unique-ingress-host # replace with the name of the constraint you want to disable
add this to the
- op: "replace"
If for some reason OPA Gatekeeper is giving you issues and blocking normal operations in your cluster, you can disable it by removing the Validating Admission Webhook definition from your cluster:
kubectl delete ValidatingWebhookConfiguration gatekeeper-validating-webhook-configuration
Gatekeeper is configured by default in this module to expose some Prometheus metrics about its health, performance, and operative information.
You can monitor and review these metrics by checking out the provided Grafana dashboard. (This requires the KFD Monitoring Module to be installed).
Go to your cluster's Grafana and search for the "Gatekeeper" dashboard.
You can also use Gatekeeper Policy Manager to view the Constraints Templates, Constraints, and Violations in a simple-to-use UI.
Two alerts are also provided by default with Gatekeeper, the alerts are triggered when the number of errors seen by the Kubernetes API server trying to contact Gatekeeper's webhook is too high. Both for Fail open (
Ignore) mode and Fail mode.
Notice that the alert for when the Gatekeeper webhook is in
Ignore mode (the default) depends on an API server metric that has been added in Kubernetes version 1.24. Previous versions of Kubernetes won't trigger alerts when the webhook is failing and in