nodeSelector: {}
tolerations: []
affinity: {}
topologySpreadConstraints: []

## Add stateful containers to have security context, if enabled MinIO will run as this
## user and group NOTE: securityContext is only enabled if persistence.enabled=true
securityContext:
  enabled: true
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000
  fsGroupChangePolicy: "OnRootMismatch"

containerSecurityContext:
  readOnlyRootFilesystem: false

.Values.priorityClassName }} priorityClassName: "{{ .Values.priorityClassName }}" {{- end }} {{- if .Values.runtimeClassName }} runtimeClassName: "{{ .Values.runtimeClassName }}" {{- end }} {{- if and .Values.securityContext.enabled .Values.persistence.enabled }} securityContext: {{ omit .Values.securityContext "enabled" | toYaml | nindent 8 }} {{- end }} {{ if .Values.serviceAccount.create }} serviceAccountName: {{ .Values.serviceAccount.name }} {{- end }} containers: - name: {{ .Chart.Name }} image: "{{ ...

### Bug or Regression

- Fix kubelet on Windows fails if a pod has SecurityContext with RunAsUser ([#129508](https://github.com/kubernetes/kubernetes/pull/129508), [@carlory](https://github.com/carlory)) [SIG Storage, Testing and Windows]

- KEP-3619: fine-grained supplemental groups policy is graduated to Beta. Note that kubelet now rejects pods with `.spec.securityContext.supplementalGroupsPolicy: Strict` when scheduled to the node that does not support the feature (`.status.features.supplementalGroupsPolicy: false`). ([#130210](https://github.com/kubernetes/kubernetes/pull/130210), [@everpeace](https://github.com/everpeace))...

- `AppArmor` profiles specified in the Pod or container `SecurityContext` were no longer copied to deprecated `AppArmor` annotations (prefix `container.apparmor.security.beta.kubernetes.io/`). Anything that inspected the deprecated annotations must be migrated to use the `SecurityContext` fields instead. ([#131989](https://github.com/kubernetes/kubernetes/pull/131989), [@tallclair](https://github.com/tallclair))

### Bug or Regression

- Fix kubelet on Windows fails if a pod has SecurityContext with RunAsUser ([#129507](https://github.com/kubernetes/kubernetes/pull/129507), [@carlory](https://github.com/carlory)) [SIG Storage, Testing and Windows]

- Fixed the documentation for the default value of the `procMount` entry in `securityContext` within a Pod.

- Implemented a new, alpha `seLinuxChangePolicy` field within a Pod-level `securityContext`, under SELinuxChangePolicy feature gate. This field allows for opting out from mounting Pod volumes with SELinux label when SELinuxMount feature is enabled (it is alpha and disabled by default now).