Add support for securityContext per deployment

[nwalens]

closes: #17744
related: #18136

This PR replaces the global "uid" and "gid" with a per deployment securityContext setting.

Fields are configured as follows:

podSecurity:
  default:
    securityContext:
      runAsUser: 50000
      fsGroup: 0
      runAsGroup: 0
    containerSecurityContext:
      runAsUser: 50000
      runAsGroup: 0
  webserver:
    securityContext:
      enabled: false
    containerSecurityContext:
      enabled: false

The default will be used in case the individual setting is disabled.

This change allows for more configurability and allows the usage of arbitrary securityContexts as permitted by the official docker images.
The issue #18136 still requires the PR #18147 for Openshift clusters since there is no option to remove securityContexts altogether.

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.

[jedcunningham]

My initial thought is we should move the component specific params from podSecurity.<component>.securityContext to <component>.podSecurity.securityContext. Basically, don't follow the lead of images, but of serviceAccount, command, args, etc. Thoughts/input @kaxil?

[potiuk]

Needs rebase (and some comments application)

[potiuk]

Hello @nwalens - can you rebase please?

[nwalens]

@potiuk the code was rebased. I'm still testing it after applying the changes @jedcunningham has requested and I am having some issues with several tests.
I'm currently checking each test and identifying the failures.

[nwalens]

Basic tests should be working fine and behaving the same as the current chart.
@jedcunningham should I remove the previous uid and gid fields from values.yaml and documentation? As far as this PR goes, they are being replaced by the podSecurity parameter.

Basically, when a configuration is not set for a component, it will default to podSecurity.securityContext or podSecurity.containerSecurityContext.

securityContext will be set for the whole Pod and containerSecurityContext for each container within the pod.
It does respect the options set for specific addons like git-sync.

[jedcunningham]

As for uid and gid, we either need to add backwards compatibility for them, or we need to wait for 2.0.0 of the chart.

One option to add backwards compatibility might be to add a template to _helper to render the default, allowing the logic of using podSecurity.securityContext or uid and gid to be contained and implemented once. Types may make it not a simple drop-in with the default | toYaml you currently have, but would still be reasonable.

[potiuk]

You need to rebase and resolve the conflicts, I am afraid.

[kaxil]

Can you fix the conflicts one more time please and mention us when you are done?

[nwalens]

@kaxil rebased as requested.

[dstandish]

any reason you did not touch pg bouncer?

[ashb]

I don't think you have a test that covers when you have a partial global security setting (say) UID, but a local security setting only GID

Could you add that please?

[dstandish]

looks good just one suggetion with the naming of the defined templates, i.e. global vs local vs airflow

obsolete

[github-actions]

The PR is likely OK to be merged with just subset of tests for default Python and Database versions without running the full matrix of tests, because it does not modify the core of Airflow. If the committers decide that the full tests matrix is needed, they will add the label 'full tests needed'. Then you should rebase to the latest main or amend the last commit of the PR, and push it with --force-with-lease.

[nwalens]

any reason you did not touch pgBouncer?

At first the intention was to cover whatever was referencing the global UID and GID parameters, in a later stage it was extended to some components like gitSync and Triggerer due to the integration they have with the main components.
I can extend it to other components as well, I just don't want to make it too big so it breaks the current helmchart behaviour.

What do you think? Should it be extended to the likes of pgBouncer and redis at this point?

@dstandish @jedcunningham

[nwalens]

I don't think you have a test that covers when you have a partial global security setting (say) UID, but a local security setting only GID

Could you add that please?

@ashb - On a second thought, I'm not sure we should test that. This PR does not allow for using UID and GID + securityContext + .securityContext.

If you set .securityContext, the values set here will be used and all other values from UID, GID and securityContext ignored. They don't add on top of each other.

The order they currently follow is .securityContext > securityContext > (UID & GID).

[jedcunningham]

Couple minor changes 👍

[jedcunningham]

Should it be extended to the likes of pgBouncer and redis at this point?

Let's leave these for a future PR.

@ash, there is already coverage for the local vs global vs uid/gid precedence, so we should be good on that front.

[jedcunningham]

Thanks for the contribution @nwalens 🎉! (also thanks for being patient)