Argo CD v2.8 and Kubernetes 1.28 Compatibility: podSecurity API Support?

Argo CD v2.8 can deploy applications to Kubernetes 1.28 clusters, but it does not "natively support" the podSecurity API because it does not need to. The Pod Security Admission controller is a Kubernetes-native feature that has been General Available since v1.25. Since Argo CD acts as a delivery mechanism, it simply applies the manifests to the cluster; the cluster's admission controller then enforces the policies based on namespace labels.

Understanding the Compatibility Gap

The confusion regarding Argo CD v2.8 and Kubernetes 1.28 often stems from the official support matrix. While Argo CD lists Kubernetes 1.22 through 1.27 as supported versions, this typically refers to the versions where the internal Argo CD components and API-interactions were fully tested. Running it on 1.28 generally works for standard GitOps operations, provided your manifests do not use deprecated APIs.

The reported reported CRD validation errors tied to v1beta1 extensions are not caused by Argo CD's version, but by the fact that Kubernetes 1.22+ removed these APIs (like extensions/v1beta1 Ingress). If your application manifests still reference these, the Kubernetes API will reject them regardless of the Argo CD version used.

Steps to Maintain Security Policies

If you are moving to a 1.28 cluster with Pod Security enabled, follow these steps to ensure security policies are maintained without deployment failures:

• Apply Namespace Labels: Instead of using deprecated PodSecurityPolicy, apply labels to your application namespaces. For example:

  kubectl label ns  pod-security.kubernetes.io/enforce=baseline --overwrite

• Adjust Argo CD Components: If Argo CD's own pods (repo-server, controller, etc.) are blocked by a "restricted" policy, use the Helm chart values to configure their securityContext. Ensure you define runAsRoot: false and seccompProfile where required.
• Validate Manifests Early: Use a server-side dry-run to see if the cluster rejects your manifests before a full sync.

Handling the kubeVersion Override

The kubeVersion override in the Helm chart is used by Helm's templating logic (e.g., if .Values.kubeVersion ...). It does not perform validation against a support range. To prevent deployment failures, you should manually verify the rendered output using the following command:

helm template arggo-cd argocd/argo-cd -f values.yaml | kubectl apply --dry-run=server

Are you seeing specific error codes during the sync, or is the failure occurring during the initial manifest generation phase?