Enables Kerberos sidecar support

[potiuk]

Enables Kerberos sidecar support

Some of the users of Airflow are using Kerberos to authenticate
their worker workflows. Airflow has a basic support for Kerberos
for some of the operators and it has support to refresh the
temporary kerberos tokens via airflow kerberos command.

This change adds support for the Kerberos side-car that connects
to the Kerberos Key Distribution Center and retrieves the
token using Keytab that should be deployed as Kubernetes Secret.

It uses shared volume to share the temporary token. The nice
thing about setting it up as a sidecar is that the Keytab
is never shared with the workers - the secret is only mounted
by the sidecar and the workers have only access to the temporary
token.

Depends on #11129

---

^ 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.

[potiuk]

cc: @jaketf

[mik-laj]

Can you add some docs to: https://github.com/apache/airflow/blob/master/chart/README.md ? You probably just need to write an additional 2-3 sentences and copy the description of this PR.

[mik-laj]

I also think it is worth adding a "Hardening container environment" section to Kerberos to describe good practices/recommendations. The excerpts from the security posture that we have written will be helpful for this. Not everyone who uses Kubernetes uses Helm. For example, I have heard about projects that only use Terraform.

[potiuk]

I also think it is worth adding a "Hardening container environment" section to Kerberos to describe good practices/recommendations. The excerpts from the security posture that we have written will be helpful for this. Not everyone who uses Kubernetes uses Helm. For example, I have heard about projects that only use Terraform.

I decided to only add a general concept description to the new production-deployment.rst where I think it belongs and will be much easier to discover. I think there will be a general overhaul of the chart documentation as currently, it's structure is a bit undefined, it contains a number of old references to Astronomer's helm repo and it's generally not yet well structured for end-user yet, and it will generally change, I guessm when we decide how we release the Chart. But I am afraid is not a priority now for anyone to fix it.

CC @dimberman -> for the far future when we get to release the Helm Chart we'd need to add much more documentation on the supported cases as the information there is rather a mixed-bag of different kinds of information. - some about installing, some about using, few features are described but many are not. Good to remember as a point that should be fulfilled when we release the chart.

[potiuk]

Please re-review :). I made the test pass with it and added the documentation.

[mik-laj]

@potiuk I think it is also worth adding information about it on the page with the title "Kerberos". I imagine that a person who would like to start using Kerberos, eg @jaketf 2 months ago, will find this page, read it and will not be able to ensure security for Kerberos in container environment. He doesn't necessarily have to use the production image, but he may want to use any docker image. This concept is universal and independent of the Production Docker image and Helm Chart. This can be done using a Docker image from Astronomer, Puckel, or any other image. If I would like to start using Kerberos, I would like to have all the information on the "Kerberos" page or there should at least be a link on this page to get more information.

[mik-laj]

Or another example:
One of our key clients prepares the Docker image on their own. They already have it tested, but they want to start using Kerberos. How is they going to find out how to do it safely? I believe they will only read the Kerberos documentation. Probably after reading current documentation, they may come up with non-recommended solutions to this problem, eg. regular rotation of the kkeytab file to ensure security.

[potiuk]

Sure. Good idea @mik-laj I did not even know it existed. I think the best way will be to link from the Kerberos page to the "production-deployment.rst".

Unfortunately, I have no idea how to link to particular sections between the docs, but I am sure you can help with that. I looked at similar doc links and tried to make the similar link but I am not sure if it will work I had to fix some spelling mistakes, so I tried to add the link from the Kerberos document to the documentation I wrote.

Unfortunately, I have very little time to understand how sphinx details and links work, so I would be really happy if you can help in it, I know you are our local expert, so I'd appreciate if you can suggest any changes to the .rst document that could make the links more useful. I'd really appreciate if you can help with that since you have all the sphinx experience.

[mik-laj]

More information about ref: https://www.sphinx-doc.org/en/1.5/markup/inline.html#role-ref

[potiuk]

Cool. Thanks. really helpful I just did not have time to read all the docs and find it. Really appreciate it.