[
https://issues.apache.org/jira/browse/TIKA-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132795#comment-18132795
]
ASF GitHub Bot commented on TIKA-5003:
--------------------------------------
aplufr opened a new pull request, #46:
URL: https://github.com/apache/tika-helm/pull/46
Set seccompProfile to RuntimeDefault and disable privilege escalation by
default so pods are admitted in namespaces enforcing the restricted Pod
Security Standard.
Declare seccompProfile in values.schema.json for both the container and pod
security contexts, and allow the common pod-level fields (fsGroup, runAs*) that
were previously rejected by additionalProperties: false.
> tika-helm chart 4.0.0 not compliant with Pod Security Standard "restricted"
> (seccompProfile not settable, allowPrivilegeEscalation defaults to true)
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TIKA-5003
> URL: https://issues.apache.org/jira/browse/TIKA-5003
> Project: Tika
> Issue Type: Bug
> Components: tika-helm
> Affects Versions: 4.0.0
> Environment: * Chart: tika v4.0.0, appVersion 4.0.0-1-full
> * Chart source: https://github.com/apache/tika-helm
> * Kubernetes: any version enforcing Pod Security Standard restricted:latest
> via Pod Security admission (namespace label
> pod-security.kubernetes.io/enforce: restricted)
> * Symptom surface: repeated ReplicaSet FailedCreate events
> Expected: the chart deploys successfully on a PSS-restricted namespace, and
> seccompProfile.type can be set through values.yaml.
> Actual: Deployment renders fine but every Pod is rejected by the Pod Security
> admission controller; no values.yaml workaround is accepted because of
> values.schema.json validation.
> Reporter: Aymeric
> Priority: Major
>
> h2. Summary
> The official Apache Tika Helm chart ({{tika}} chart v4.0.0, appVersion
> {{4.0.0-1-full}}, source https://github.com/apache/tika-helm) cannot be
> deployed on a namespace enforcing the Kubernetes Pod Security Standard
> {{restricted:latest}}. Pods are rejected at admission time:
> {code}
> Error creating: pods "..." is forbidden: violates PodSecurity
> "restricted:latest":
> seccompProfile (pod or container "tika" must set
> securityContext.seccompProfile.type
> to "RuntimeDefault" or "Localhost")
> {code}
> Two distinct defects are involved:
> # The chart defaults do not set {{seccompProfile}} (and default
> {{allowPrivilegeEscalation: true}}), so the rendered Pod is not
> PSS-{{restricted}} compliant.
> # The bundled {{values.schema.json}} uses {{additionalProperties: false}} and
> does not declare {{seccompProfile}}, so users cannot add it through
> {{values.yaml}} either: Helm rejects any override with {{Additional property
> seccompProfile is not allowed}}.
> h2. Steps to reproduce
> # Install the chart into a namespace labelled
> {{pod-security.kubernetes.io/enforce: restricted}}.
> # Run {{kubectl get events -n <ns>}} and observe repeated {{FailedCreate ...
> violates PodSecurity "restricted:latest": seccompProfile ...}} events.
> # Try to fix it by adding to {{values.yaml}}:
> {code:yaml}
> securityContext:
> seccompProfile:
> type: RuntimeDefault
> {code}
> # Run {{helm lint .}} / {{helm template . -f values.yaml}}: validation fails
> with {{Additional property seccompProfile is not allowed}}.
> h2. Root cause
> h3. Defaults do not satisfy PSS restricted
> {{values.yaml}} defaults:
> {code:yaml}
> podSecurityContext: {} # empty, no seccompProfile at pod level
> securityContext:
> allowPrivilegeEscalation: true # forbidden by PSS "restricted"
> capabilities:
> drop: ["ALL"]
> readOnlyRootFilesystem: true
> runAsNonRoot: true
> runAsUser: 35002
> runAsGroup: 35002
> # no seccompProfile here either
> {code}
> {{templates/deployment.yaml}} renders these verbatim at pod level and at
> container level. Neither level receives a {{seccompProfile}}, so the Pod
> violates PSS {{restricted}} (it must be {{RuntimeDefault}} or {{Localhost}}).
> h3. The schema forbids the workaround
> In {{values.schema.json}}:
> * the top level sets {{"additionalProperties": false}};
> * the {{securityContext}} block (around lines 435-509) has a fixed list of
> {{properties}} ({{allowPrivilegeEscalation}}, {{capabilities}},
> {{readOnlyRootFilesystem}}, {{runAsGroup}}, {{runAsNonRoot}}, {{runAsUser}})
> with no {{seccompProfile}};
> * the {{podSecurityContext}} block (around lines 314-319) sets
> {{"additionalProperties": false}} with no {{properties}} at all, so only {{}}
> validates.
> Therefore {{seccompProfile}} cannot be expressed under either block.
> h2. Impact
> * The chart is broken out of the box on any PSS-{{restricted}} cluster
> (common hardened baseline).
> * No supported escape hatch via {{values.yaml}}.
> * The default {{allowPrivilegeEscalation: true}} remains a second
> PSS-{{restricted}} violation even once seccomp is addressed.
> h2. Suggested fix
> h3. values.yaml
> {code:diff}
> securityContext:
> # -- Allow privilege escalation for the container
> - allowPrivilegeEscalation: true
> + allowPrivilegeEscalation: false
> capabilities:
> drop:
> - ALL
> readOnlyRootFilesystem: true
> runAsNonRoot: true
> runAsUser: 35002
> runAsGroup: 35002
> + # -- Seccomp profile for the container (required by PSS "restricted")
> + seccompProfile:
> + type: RuntimeDefault
> {code}
> Optionally, if pod-level seccomp is preferred:
> {code:diff}
> podSecurityContext:
> - {}
> + seccompProfile:
> + type: RuntimeDefault
> {code}
> h3. values.schema.json
> Declare {{seccompProfile}} in both blocks (keeping {{additionalProperties:
> false}}):
> {code:json}
> "seccompProfile": {
> "additionalProperties": false,
> "description": "Seccomp profile for the container",
> "properties": {
> "type": {
> "description": "Type of seccomp profile (RuntimeDefault or Localhost
> for restricted)",
> "enum": ["Unconfined", "RuntimeDefault", "Localhost"],
> "title": "type",
> "type": "string"
> },
> "localhostProfile": {
> "description": "Localhost profile name (required when type is
> Localhost)",
> "title": "localhostProfile",
> "type": "string"
> }
> },
> "required": ["type"],
> "title": "seccompProfile",
> "type": "object"
> }
> {code}
> Also add {{seccompProfile}} to the {{securityContext.required}} array, and
> introduce a {{properties}} block in {{podSecurityContext}} (currently absent)
> with the same definition.
> h2. References
> * Pod Security Standards:
> https://kubernetes.io/docs/concepts/security/pod-security-standards/
> * seccompProfile API:
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#seccompprofile-v1-core
> * Helm schema files: https://helm.sh/docs/topics/charts/#schema-files
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
