Emergency disable

In an emergency, operations teams might need to perform actions that SUSE Security Admission Controller would block.

This document explains how to disable Admission Controller so operations teams can address cluster failures. After resolving the situation, operations teams can restart Admission Controller.

Disable Admission Controller

First, stop the Admission Controller controller. You do this by scaling its Deployment to zero:

kubectl scale deployment suse-sec-adm-controller-ssac \
  --replicas=0 \
  -n suse-sec-adm-controller

Ensure you use the name of the Namespace where the Admission Controller stack is deployed. Here, the stack is deployed in the suse-sec-adm-controller Namespace.

Next, delete all the ValidatingWebhookConfigurations and MutatingWebhookConfigurations created by Admission Controller:

# Delete all the ValidatingWebhookConfiguration created by Admission Controller
kubectl delete validatingwebhookconfigurations \
  -l app.kubernetes.io/part-of=kubewarden

# Delete all the MutatingWebhookConfiguration created by Admission Controller
kubectl delete mutatingwebhookconfigurations \
  -l app.kubernetes.io/part-of=kubewarden

Restore Admission Controller

When the emergency is over, restore the Admission Controller stack by bringing back the Admission Controller:

kubectl scale deployment suse-sec-adm-controller-ssac \
  --replicas=1 \
  -n suse-sec-adm-controller

  • Ensure you use the name of the Namespace where the Admission Controller stack is deployed. Here, the stack is deployed in the suse-sec-adm-controller Namespace.

  • Ensure you scale the controller back to its original value. This example assumes there’s only one replica of the controller running.

Once the controller is running, it reconciles the deployed policies. The ValidatingWebhookConfiguration and MutatingWebhookConfiguration resources of the policies, previously deleted, are recreated, thus enforcing the policies.

The controller doesn’t recreate its own webhook configurations, kubewarden-controller-validating-webhook-configuration and kubewarden-controller-mutating-webhook-configuration, which the Helm chart installs. To recreate them, roll back the Helm release to its current revision. Get the revision number:

helm history suse-sec-adm-controller -n suse-sec-adm-controller --max 1

Then roll back to it, replacing <revision> with the number in the REVISION column:

helm rollback suse-sec-adm-controller <revision> -n suse-sec-adm-controller --wait