Migrate from Pod Security Policy to SecurityContext

[pierluigilenoci]

What would you like to be added:

Pod Security Policies are deprecated and will be removed in Kubernetes v1.25.

Migration to another alternative is necessary. To date there are some alternative solutions:

• Pod Security Admission
• OPA Gatekeeper
• Kyverno

A solution that is ecumenical and covers all the aforementioned alternatives is the use of Security Context directly in the manifest of the chart.

A possible solution would be to implement all the major alternatives within the chart but it is certainly a more onerous job.

Why is this needed:

For the reasons already explained above.

/kind feature

[pierluigilenoci]

@stevehipwell could you please take a look?

[stevehipwell]

@pierluigilenoci are you suggesting that the security context for the pod and primary container need updating or are you asking for something else? AFAIK the security admission control is namespace based so out of the scope of a chart, but the chart should be following best practices and potentially offer a non-mutating PSP version to use as a pre-migration step.

[pierluigilenoci]

@stevehipwell I suggest adding the securityContext as default in the chart so that the software runs as restrictively as possible and limiting the use of the PSP only if the K8s version is < 1.25.

For example, this is completely missing:

capabilities:
  drop:
    - ALL

[stevehipwell]

@pierluigilenoci I think the security context needs to come form the Metrics Server maintainers, the Helm chart copies what's in the manifest and also provides the ability to set the pod security policy in addition. AFAIK this change isn't required to enable pod admission, it just means that it needs to be configured correctly (as it will need to be for multiple other pods running in kube-system). I do agree that the PSP resources should be gated on the K8s version, I'll open a PR to do this.

@serathius do you have any plans to change the manifest security policy configuration?

[pierluigilenoci]

@stevehipwell obviously, the request must be evaluated by the maintainers and implemented in the chart only after it is approved.

I would also like to have the opinion of @serathius about it.

[stevehipwell]

@pierluigilenoci the chart usually tracks the installation manifest, so changes would be expected there first which would then be implemented as the defaults in the chart. This issue is currently labelled for the chart but I think it's really about Metrics Server in general.

[pierluigilenoci]

@stevehipwell do you think it might make sense to create a new issue for this more general aspect?

[stevehipwell]

@stevehipwell do you think it might make sense to create a new issue for this more general aspect?

@pierluigilenoci that might be a good idea, maybe pitched more about reducing default permissions ready for pod security admission? This issue could then be renamed to track getting any changes into Helm?

[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

[pierluigilenoci]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[pierluigilenoci]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[pierluigilenoci]

/remove-lifecycle stale

[pierluigilenoci]

@stevehipwell, I lost track of this issue and never created the follow-up one; sorry.

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[pierluigilenoci]

/remove-lifecycle stale

[treksler]

https://github.com/kubernetes-sigs/metrics-server/pull/1471

at the very least we should avoid making psps in 1.25 and above

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[pierluigilenoci]

/remove-lifecycle stale

[stevehipwell]

@pierluigilenoci PSP is disabled for K8s versions where it's no longer supported. For the Helm chart the pod and container security contexts are both configurable. Could you expand on the actual changes you'd like to see?

[pierluigilenoci]

We talked about it almost two years ago: https://github.com/kubernetes-sigs/metrics-server/issues/1063#issuecomment-1209504970

[stevehipwell]

@pierluigilenoci I read that comment again but your most recent comment was that you hadn't followed up on this.

As the replacement for PSPs are Pod Security Standards you might be best off documenting how the Metrics Server defaults don't work with them and what you think the defaults should be changed to.