Can you also add the list of subresources for mutating-webhook-configuration as well?

 - pods/ephemeralcontainers
  - pods/exec
  - pods/log
  - pods/eviction
  - pods/portforward
  - pods/proxy
  - pods/attach
  - pods/binding
  - pods/resize
  - deployments/scale
  - replicasets/scale
  - statefulsets/scale
  - replicationcontrollers/scale
  - services/proxy
  - nodes/proxy
  - services/status

✔️ Updated the kubebuilder annotation in pkg/webhook/mutation.go with these values

Thanks for the PR @ianstanton!

Adding these resources to the MutatingWebhookConfiguration can introduce security risks and, performance impacts. I recommend removing these from the default. Users can always add if needed for their specific use cases based on their own security and performance analysis.

Security Risks:

pods/exec: Allowing exec operations can be risky as it enables direct command execution within containers, which can be exploited if not properly controlled.
pods/log: Access to logs can expose sensitive information.
pods/proxy, services/proxy, nodes/proxy: Proxy operations can be exploited to redirect traffic, potentially exposing internal services.
pods/attach: Attaching to pods can provide direct access to the container's processes and data.
pods/ephemeralcontainers: These can be used to add ephemeral containers to running pods, which could be exploited if proper security measures are not in place.
pods/binding: This operation binds a Pod to a specific Node, which can be misused to affect workload scheduling and performance.
pods/resize: Resizing pods can impact resource allocation and disrupt services.

Performance Impact:

The webhook will intercept more requests, potentially increasing the latency and load on the API server.
Frequent mutations on high-traffic resources (like pods/exec or pods/log) can lead to performance bottlenecks.

We need to balance the need for mutation with the potential risks and performance overhead it introduces. Limiting the scope to only necessary resources and operations is a good practice.

@ritazh Good call, thanks for pointing this out. I'll revert this piece soon.

changes in deploy dir are overwritten with each release, so please remove any changes in gatekeeper.yaml file.

👍 Removed these changes

Any changes in charts dir is overwritten in release, please remove any changes in this dir.

Got it! Looks like these changes are applied in the manifest_staging dir when we run make generate.

Yip! that is fine. We want these changes to manifest_staging. You can find out more on contributing to helm chart and overall here - https://open-policy-agent.github.io/gatekeeper/website/docs/help#contributing-to-helm-chart. Thanks again for the PR!