You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -692,7 +693,7 @@ This chart includes secure defaults that can be overridden as needed:
692
693
693
694
### Security Context Defaults
694
695
695
-
By default, pods run with the following security settings:
696
+
When `webservice.securityDefaults` is `true` (the default), the chart renders the following baseline:
696
697
697
698
```yaml
698
699
# Pod Security Context
@@ -712,21 +713,50 @@ securityContext:
712
713
- ALL
713
714
seccompProfile:
714
715
type: RuntimeDefault
716
+
```
715
717
716
-
To override these defaults, set `webservice.securityContext` or `webservice.containerSecurityContext`:
718
+
`webservice.securityContext` and `webservice.containerSecurityContext` are merged **on top** of those defaults — user keys win, unset keys keep the default. So a partial override works as you'd expect:
717
719
718
720
```yaml
719
721
webservice:
720
722
securityContext:
721
-
runAsUser: 2000
722
-
fsGroup: 2000
723
+
runAsUser: 2000 # overrides the default 1000
724
+
fsGroup: 2000 # overrides the default 1000
725
+
# runAsNonRoot: true # still applied from the defaults
723
726
containerSecurityContext:
724
727
readOnlyRootFilesystem: false
725
728
seccompProfile:
726
729
type: Localhost
727
730
localhostProfile: "profiles/custom.json"
728
731
```
729
732
733
+
#### Disabling the defaults (root user, writable filesystem, …)
734
+
735
+
Setting `securityContext: {}` / `containerSecurityContext: {}` is **not enough** to opt out — they're already `{}` by default, and the defaults still render on top. Use `securityDefaults: false` to start from a clean slate (no `securityContext` block emitted at all → root user, writable rootfs, default caps):
736
+
737
+
```yaml
738
+
webservice:
739
+
securityDefaults: false
740
+
```
741
+
742
+
You can still selectively add fields on top — e.g. run as root without forcing any other hardening:
743
+
744
+
```yaml
745
+
webservice:
746
+
securityDefaults: false
747
+
containerSecurityContext:
748
+
runAsUser: 0
749
+
```
750
+
751
+
#### Pod-level vs container-level — why both?
752
+
753
+
Kubernetes lets several fields (`runAsUser`, `runAsGroup`, `runAsNonRoot`, `seccompProfile`, `seLinuxOptions`) live at **either** level. Container-level wins; pod-level acts as the default for every container in the pod (main, sidecars from `additionalContainers`, init containers). The other fields are scoped:
754
+
755
+
- **Pod-only** (volume/kernel attrs shared across the pod): `fsGroup`, `fsGroupChangePolicy`, `supplementalGroups`, `sysctls`
The defaults set `runAsUser` / `runAsNonRoot` at both levels on purpose — pod-level covers any sidecar you add via `additionalContainers`, container-level locks the main container.
759
+
730
760
### Resource Defaults
731
761
732
762
If no resources are specified, the following defaults are applied:
@@ -692,7 +693,7 @@ This chart includes secure defaults that can be overridden as needed:
692
693
693
694
### Security Context Defaults
694
695
695
-
By default, pods run with the following security settings:
696
+
When `webservice.securityDefaults` is `true` (the default), the chart renders the following baseline:
696
697
697
698
```yaml
698
699
# Pod Security Context
@@ -712,21 +713,50 @@ securityContext:
712
713
- ALL
713
714
seccompProfile:
714
715
type: RuntimeDefault
716
+
```
715
717
716
-
To override these defaults, set `webservice.securityContext`or`webservice.containerSecurityContext`:
718
+
`webservice.securityContext`and`webservice.containerSecurityContext` are merged **on top** of those defaults — user keys win, unset keys keep the default. So a partial override works as you'd expect:
717
719
718
720
```yaml
719
721
webservice:
720
722
securityContext:
721
-
runAsUser: 2000
722
-
fsGroup: 2000
723
+
runAsUser: 2000 # overrides the default 1000
724
+
fsGroup: 2000 # overrides the default 1000
725
+
# runAsNonRoot: true # still applied from the defaults
723
726
containerSecurityContext:
724
727
readOnlyRootFilesystem: false
725
728
seccompProfile:
726
729
type: Localhost
727
730
localhostProfile: "profiles/custom.json"
728
731
```
729
732
733
+
#### Disabling the defaults (root user, writable filesystem, …)
734
+
735
+
Setting `securityContext: {}` / `containerSecurityContext: {}` is **not enough** to opt out — they're already `{}` by default, and the defaults still render on top. Use `securityDefaults: false` to start from a clean slate (no `securityContext`block emitted at all → root user, writable rootfs, default caps):
736
+
737
+
```yaml
738
+
webservice:
739
+
securityDefaults: false
740
+
```
741
+
742
+
You can still selectively add fields on top — e.g. run as root without forcing any other hardening:
743
+
744
+
```yaml
745
+
webservice:
746
+
securityDefaults: false
747
+
containerSecurityContext:
748
+
runAsUser: 0
749
+
```
750
+
751
+
#### Pod-level vs container-level — why both?
752
+
753
+
Kubernetes lets several fields (`runAsUser`, `runAsGroup`, `runAsNonRoot`, `seccompProfile`, `seLinuxOptions`) live at **either** level. Container-level wins; pod-level acts as the default for every container in the pod (main, sidecars from `additionalContainers`, init containers). The other fields are scoped:
754
+
755
+
- **Pod-only** (volume/kernel attrs shared across the pod): `fsGroup`, `fsGroupChangePolicy`, `supplementalGroups`, `sysctls`
The defaults set `runAsUser` / `runAsNonRoot` at both levels on purpose — pod-level covers any sidecar you add via `additionalContainers`, container-level locks the main container.
759
+
730
760
### Resource Defaults
731
761
732
762
If no resources are specified, the following defaults are applied:
0 commit comments