Release Candidate v2.0.0-rc.0

Gatekeeper Policy Manager release v2.0.0

Welcome to the release of Gatekeeper Policy Manager v2.0.0, maintained with ❤️ by the team SIGHUP by ReeVo.

This version replaces the Python backend with a new one written in Go, adds views for Gatekeeper mutations and events, adds support for Kubernetes 1.36 and updates all dependencies. The web interface is the one you already know.

Because this is a large change, it is published first as a release candidate. Try it on a non-production cluster and tell us what breaks.

You do not need to change how you deploy GPM. The container image, the Kubernetes manifests and the Helm chart all work the same way. Read the breaking changes below before you upgrade.

New features 🌟

• Mutations view. You can now see the Gatekeeper mutation policies in your cluster, with their details and the operations they apply.
• Events view. You can now see the events that OPA Gatekeeper sends. This is an alpha feature. GPM needs permission to read events for this view to work. Use GPM_EVENTS_SOURCE to choose which event source to show. The default is gatekeeper-webhook.
• You can limit the events view to one namespace. By default GPM reads events from every namespace, which needs read access to events in the whole cluster. Set GPM_EVENTS_NAMESPACE to the namespace that OPA Gatekeeper runs in to make that access smaller. In the Helm chart, set config.eventsNamespace and the chart creates a Role in that namespace instead of a cluster-wide rule.
• Helm chart: RBAC for the mutations and events views. The chart grants GPM the read access that these two new views need. It also accepts config.eventsSource.
• The violations report says which cluster it comes from. Each report now shows the address of the Kubernetes API server and the time it was generated.
• You can change the address GPM listens on with the new GPM_LISTEN_ADDRESS variable. The default is :8080, the same port as before.
• You can connect to clusters with a certificate GPM does not trust. Set GPM_SKIP_TLS_VERIFY=true to skip the TLS certificate check against the Kubernetes API. This is needed on some clusters, for example on EKS, where the cluster certificate is missing information that Go requires. Only use it on a network you trust, because it removes a security check. When a connection fails because of a certificate, GPM now says so clearly and points you to this option.
• You can serve GPM from a subpath, for example example.com/gpm, instead of the domain root. Build the image with --build-arg PUBLIC_URL=/gpm. Then configure your reverse proxy to remove the subpath before it forwards the request. OIDC login works on a subpath too. The published image uses the root path. If you need a subpath, build your own image.
• The session cookie is encrypted. GPM signs the cookie and also encrypts it, with two keys that it derives from GPM_SECRET_KEY. In 1.x the cookie was signed only, so anyone who held it could read the user name out of it. Everyone has to log in again once. The same happens whenever you change GPM_SECRET_KEY, because the keys come from it. GPM sends those users to the login page. GPM does not keep sessions on the server, so a logout cannot cancel a copy of the cookie that someone took to another machine. Such a copy stays valid until GPM_SESSION_MAX_AGE expires it.
• OIDC login is still supported. Set GPM_AUTH_ENABLED=OIDC to require users to sign in, exactly as in 1.x — the same environment variables and the same /oidc-auth redirect URI, so an existing configuration keeps working. GPM reads your provider's settings from its issuer URL, or you can give it each endpoint by hand. Logging out of GPM also logs you out of the provider when it supports that. A session lasts 8 hours by default. Use GPM_SESSION_MAX_AGE to change this.
• The container image is smaller. It contains no shell and no package manager, which makes it easier to scan and to keep free of vulnerabilities.
• Helm chart: the liveness and readiness probes are now configurable. You can turn each one off and change its path, port and timings under livenessProbe and readinessProbe. They keep working as before if you change nothing.
• Helm chart: you no longer have to put the secret key in your values file. Set config.secretRef to the name of a secret you already manage, with the key in a secretKey field. config.secretKey still works if you prefer to set the value directly. The chart installs with neither set, which suits the default anonymous mode that needs no secret. OIDC still needs a strong GPM_SECRET_KEY (see the breaking changes).

Breaking changes 💔

• More of GPM now requires a login. When OIDC is on, the list of clusters (/api/v1/contexts), the mutations view and the events view need a session, which was not the case in 1.x. Only the health check and the endpoint that reports whether authentication is on stay open.
• OIDC now needs a strong secret key. When GPM_AUTH_ENABLED=OIDC, GPM refuses to start if GPM_SECRET_KEY is still the published 1.x default or shorter than 16 characters. Set it to a long random string. GPM uses it to sign and encrypt the session cookie.
• The kubeconfig path inside the container changed from /home/gpm/.kube/config to /home/nonroot/.kube/config.
• Log levels changed. GPM_LOG_LEVEL accepts DEBUG, INFO, WARN and ERROR, in any case. GPM no longer accepts WARNING, CRITICAL, FATAL or NOTSET, which the Python backend took. An invalid value gives a warning and INFO.
• The Helm chart no longer creates a HorizontalPodAutoscaler. The autoscaling.* values were removed. The template used a Kubernetes API that was removed in Kubernetes 1.26, so it could not work on any recent cluster.

Upgrade procedure

1. If you protect GPM with OIDC, set GPM_SECRET_KEY to a long random string, because GPM refuses to start with the 1.x default or a key shorter than 16 characters. Your other OIDC settings keep working. Check that <GPM_OIDC_REDIRECT_DOMAIN>/oidc-auth is registered with your provider, and set GPM_PREFERRED_URL_SCHEME=https if you serve GPM over TLS. Everyone will have to log in again once, because the session format changed.
2. If you mount a kubeconfig to reach more than one cluster, change the mount path to /home/nonroot/.kube/config, or set KUBECONFIG to the path you use.
3. If you set GPM_LOG_LEVEL, check that the value is DEBUG, INFO, WARN or ERROR.
4. If you enabled autoscaling in the Helm chart, remove the autoscaling.* values and create your own HorizontalPodAutoscaler that targets the GPM deployment.
5. Update the image tag, then apply the manifests or upgrade the Helm release as usual.