Add pod security admission labels to CAPZ provider namespace

[chrischdi]

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

As an operator I would like to set the baseline to enforce at the pod security admission configuration on my management cluster for operating a secure management cluster.

Currently when using CAPI with CAPZ, all capi namespaces except capz-system are compliant to the baseline pod security admission profile.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

As long as the DaemonSet capz-nmi is part of the capz provisioning, the namespace capz-system will require the privileged profile, because it makes use of hostPath volumes and runs as root user.

It is possible to set the cluster-wide enforce policy to baseline when provisioning CAPD using one of the following approaches:

1. Set the capz-system namespace to enforce, audit and warn on privileged.
2. Add the capz-system namespace to the namespace excemptions in the pod security admission configuration.

I would propose to go with solution 1 (as also done for CAPD kubernetes-sigs/cluster-api#7446) and add the following labels to the capz-system namespace at the namespace.yaml resource file:

  pod-security.kubernetes.io/enforce: privileged
  pod-security.kubernetes.io/warn: privileged
  pod-security.kubernetes.io/audit: privileged

• optional: add a test or adjust tests which enable enforce: baseline for the whole management cluster to test compatibility of CAPZ to the baseline profile (The config will need to except kube-system because kube-system will almost always require the privileged profile for CNI related daemonsets).

Additional information:

• We should track moving the policy settings to restricted policy when switching to workload identity in the future. (maybe requires a follow-up issue)

Environment:

• cluster-api-provider-azure version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

[chrischdi]

For propably more context: https://kubernetes.slack.com/archives/CEX9HENG7/p1667559556085549

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[chrischdi]

/remove-lifecycle stale

[chrischdi]

This was implemented in:

• add explicit securityContexts to the controller and namespace label for privileged #3399

Thus closing.

Worth a note is that CAPZ can be improved from security perspective after:

• Migrate from AAD pod identity to Azure Workload Identity #2205

was implemented, by using the policy baseline or restricted.

/close

[k8s-ci-robot]

@chrischdi: Closing this issue.

In response to this:

This was implemented in:

• add explicit securityContexts to the controller and namespace label for privileged #3399

Thus closing.

Worth a note is that CAPZ can be improved from security perspective after:

• Migrate from AAD pod identity to Azure Workload Identity #2205

was implemented, by using the policy baseline or restricted.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.