Description

My current understanding, is that the methods documented here outline the ways we can authorize AWS Secrets Manager or AWS Systems Manager as a Secrets Backend. This requires managing authorization via Environment Variables or Profiles defined in an .aws/config file.

This does not include the Assume Role methods and configuration framework offered by the AWSBaseHook. I am proposing we extend the Secrets Backend integrations, so that they can be configured in a similar manner.

Use case/motivation

This would enable users to have a consistent authorization and configuration framework (with the Hooks/Operators) when connecting to AWS Secrets Backends. This could also reduce the number of cases where users need to deploy Access & Secret Keys to their Airflow environment.

For example, users could pass a Role in the BACKEND_KWARGS for the Worker or Scheduler (once authorized) to assume to connect to the service powering their Secrets Backend.

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct