en/latest/workflow-pod-security-context/

[giscus[bot]]

en/latest/workflow-pod-security-context/

https://argo-workflows.readthedocs.io/en/latest/workflow-pod-security-context/

[joebowbeer]

pod security policy was removed in k8s 1.25 and replaced with pod and container security context.

[agilgur5]

in k8s 1.25 and replaced with pod and container security context.

Pod and container securityContext have existed much, much longer than that. That is what this page is about as well, which also predates 1.25 by years.

PSPs were an enforcement mechanism that were not very intuitive and so were replaced with PSA / PSS / policy controllers.

None of those change usage of securityContext, but they may change enforcement of securityContext

[joebowbeer]

@agilgur5 My comment refers to the following, which even links to the PSP docs:

This is likely to be necessary if you have a pod security policy. You probably can't use the Docker executor if you have a pod security policy.

[agilgur5]

Yes I am aware. The PSP docs also themselves say that.

I was specifically responding to the part of your comment saying:

replaced with pod and container security context.

which is not accurate (nor what the PSP docs say).

---

The docs line is still accurate; if you're using PSPs, PSA, or similar, it is likely still necessary to use securityContext.
Argo also supports versions of k8s prior to 1.25, which was only EoL 6 months ago and is still supported by certain vendors, e.g. EKS, so it is still relevant. If you'd like to update the line to include PSA and similar, PR welcome.

The Docker executor part is outdated, see #12975

[joebowbeer]

Restating my comment as a suggestion:

Mention of PSP, which was removed in k8s 1.25, should be removed from this page.

PSP has been deprecated since k8s 1.21 and was last seen in k8s 1.24, which reached EOL 9 months ago (28 Jul 2023).

Though it looks like (?) Argo Workflows 3.4 might still support k8s 1.24 (really?)

In any event, I think this unqualified mention of something that no longer exists is confusing, which is why I added this comment.

I suggest either removing the mention or adding a qualifier such as "which has been deprecated since Kubernetes 1.21".

As for the statement that PSP has been replaced by pod and container security contexts, this was made from the perspective of the security benchmarks and best practices. Shortly after PSP was deprecated, the existing references to PSP were replaced with guidelines for pod and container security context.

[agilgur5]

Though it looks like (?) Argo Workflows 3.4 might still support k8s 1.24 (really?)

It does. In fact, 3.4 might even support lower than that -- part of the test matrix tests k8s 1.21.

something that no longer exists

They do still exist for many users. EKS still supports 1.23 and even 1.21. I literally spoke to a user on Slack with a PSP error yesterday. I was explaining PSPs to a new k8s SRE team less than a year ago (kOps lags behind k8s, and the enterprise internal version we had at that job lagged even further behind. That's pretty common though unfortunately, there's much older software being supported all over, enough so to be a sizeable chunk of sales strategy of commercial extended support).

In general, we should keep around docs for longer than is strictly necessary as there will always be users on deprecated versions. There are still plenty of users on Argo 3.3 unfortunately too, which isn't supported either.
We also only landed versioned docs recently (#11390), so older things (including older Argo things) were also left in intentionally prior to that. I am removing some things per #12975, but will still leave them in older versions of the docs, even ones that no longer support the feature.
Broadly speaking, as a general rule of thumb, leave docs for something that is 1-2 versions behind support.

or adding a qualifier

Yes I think this would be more of a middle ground between different demographics of users, each who may be more or less confused by a wholesale removal.
We can use the word "legacy" or "deprecated". It would also make sense to include PSA, PSS, et al, as I wrote above.

Shortly after PSP was deprecated, the existing references to PSP were replaced with guidelines for pod and container security context.

I'm pretty sure you're referring to PSS. securityContexts were still best practice before them, PSS just introduced standards and terminology that could be enforced on them by k8s itself (via PSA) and other tools. PSS basically formalized what the default PSPs already enforced.

[joebowbeer]

@agilgur5 #12990

[agilgur5]

Thanks @joebowbeer!