ecerulm opened a new issue, #27318:
URL: https://github.com/apache/airflow/issues/27318
### Official Helm Chart version
1.7.0 (latest released)
### Apache Airflow version
2.4.2
### Kubernetes Version
1.23
### Helm Chart configuration
```
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
```
### Docker Image customisations
_No response_
### What happened
I have a namespace configured with the [PSS restricted (pod security
standard
restricted)](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted)
and airflow helm chart is not deployable in that namespace because the
pods/containers are not compliant with the "restricted" policy (and I don't
think is there any reason why they couldn't be made compliant)
```
Error creating: pods "airflow-run-airflow-migrations-2frnr" is forbidden:
violates PodSecurity "restricted:v1.23": allowPrivilegeEscalation != false
(container "run-airflow-migrations" must set
securityContext.allowPrivilegeEscalation=false), unrestricted capabilities
(container "run-airflow-migrations" must set
securityContext.capabilities.drop=["ALL"])
```
### What you think should happen instead
I think the helm chart should provide
* default container's securityContext
[SecurityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
in addition to the currently provided pod's securityContext
[PodSecurityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core).
Things like the capabilities, and `allowPrivilegeEscalation: false` can only
be set at the container's securityContext and not on the PodSecurityContext
* the default container securityContext in the helm chart should be
already compliant with the restricted PSS / PSA (pod security admission)
* the helm chart should allow to override the containers securityContext
(currently only allows to override the pod's securityContext)
In other words, it should be deployable into a namespace with PSA (pod
security admissiont) set to "restricted" without having to make any
modification to the helm values (values.yaml)
### How to reproduce
Create a kubenetes Namespace
```
kind: Namespace
apiVersion: v1
metadata:
name: airflow
creationTimestamp: '2022-10-27T11:26:18Z'
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: v1.23
```
Deploy there,
You will see that the Job `airflow-run-airflow-migrations` would be stuck/
forbidden to run with
```
Error creating: pods "airflow-run-airflow-migrations-2frnr" is forbidden:
violates PodSecurity "restricted:v1.23": allowPrivilegeEscalation != false
(container "run-airflow-migrations" must set
securityContext.allowPrivilegeEscalation=false), unrestricted capabilities
(container "run-airflow-migrations" must set
securityContext.capabilities.drop=["ALL"])
```
### Anything else
I guess I should make a case why is important that airflow complies with the
PSS restricted.
Running all the pods/container under the PSS restricted improves security in
the case that somebody "hacks" that airflow. So even if they get a shell to the
container, they can't become root in the container, and also they can't exploit
any capabilities given to the container since the container must have drop all
[capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html) under
the PSS restricted.
As a security-concerned system administrator I want to run all kubernetes
workloads under the least privilege possible (hardening).
I do believe that there is no reason to for airflow to run with
`allowPrivilegeEscalation: true` , or to run with linux any capabilities.
### Are you willing to submit PR?
- [X] Yes I am willing to submit a PR!
### Code of Conduct
- [X] I agree to follow this project's [Code of
Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
