A potential risk of porch which can be leverage to make cluster-level privilege escalation about nephio HOT 3 OPEN

@nyrahul @adetalhouet
Dear porch maintainers:
I am Nanzi Yang, the reporter of this potential vulnerability. I understand that the proch do need the MutatingWebhookConfuguration related permission. As far as I am concerned, perhaps you can use Gatekeeper or OPA to restrict the resources that a MutatingWebhookConfiguration can listen to and modify.

Here's a basic example using Gatekeeper:
ConstraintTemplate

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: mutatingwebhookrestriction
spec:
  crd:
    spec:
      names:
        kind: MutatingWebhookRestriction
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package mutatingwebhookrestriction

        deny[msg] {
          input.review.kind.kind == "MutatingWebhookConfiguration"
          webhook := input.review.object.webhooks[_]
          resource := webhook.rules[_].resources[_]
          not allowed_resource(resource)

          msg := sprintf("MutatingWebhookConfiguration cannot operate on resource: %v", [resource])
        }

        allowed_resource(resource) {
          resource == "pods"
        }

*** Constraint***

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: MutatingWebhookRestriction
metadata:
  name: restrict-mutating-webhook
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["MutatingWebhookConfiguration"]

The ConstraintTemplate defines a new constraint template MutatingWebhookRestriction with Rego logic to check resources in the MutatingWebhookConfiguration. The Constraint Applies this template to match all MutatingWebhookConfiguration resources.

This setup allows you to restrict users from creating MutatingWebhookConfiguration that operates on certain resources, for example, only allowing operations on pods. You can adjust the Rego logic to fit your specific requirements.

The example provided is just a starting point. The core idea is to use OPA or Gatekeeper to restrict which resources a MutatingWebhookConfiguration can listen to and modify. You can extend this approach based on your specific needs.

Looking forward to your reply.
Regards,
Nanzi Yang

from nephio.

/assign @nyrahul

from nephio.

In many cases, there is a practical reason to provide Create/Update permissions for mutatingwebhooks. In this case, the MutatingWebhookConfiguration handling is needed for porch for rotating it’s certificate for TLS comms between kube-apiserver and porch-server. However, the general sense in the team is that we might have over provisioned access for other resources/verbs. We need to do a periodic assessment about excessive permissions issued to any serviceaccounts/users/resources in Nephio cluster along with the development team. Will keep you posted on the same. Many thanks for bringing this to our notice.

Will bring this up in the SIG-Automation and SIG-Security groups next week.

from nephio.