harshit283 opened a new issue, #43758:
URL: https://github.com/apache/airflow/issues/43758

   ### Description
   
   We are deploying latest version of airflow on Azure Kubernetes cluster with 
components of airflow like web/worker/scheduler etc. running on different AKS 
pods, this is achieved using helm charts
   We are using Azure Postgres SQL service as Airflow Metadata Database
   
   Now for the airflow pods to authenticate to Postgres SQL a connection string 
is used which comprises of host, username, password, port etc. [Code 
reference](https://github.com/apache/airflow/blob/main/airflow/settings.py#L462)
 where the connection string is read from the config to initialize a DB session 
object for handling DB operations
   
   This static connection string is not the safest of options and we want to 
use [Azure AAD based 
authentication](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity)
 which eliminates the need to store static passwords.
   If we leverage this managed identity authentication mechanism instead of 
static password we can generate on demand short lived tokens and use those as 
passwords while connecting to Postgres which essentially means connection 
string will be a dynamic value
   
   One possible way to solve this issue is that since connection string is 
formed using environment variables we can update the environment variables and 
restart airflow pods but restarting pods on every token refresh is not efficient
   Hence we are looking into an optimal way to handle this in airflow code by 
perhaps a provider specific implementation of this Session class but not sure 
that is the right way, we are completely new to Airflow hence some guidance 
will really help :)
   Hoping the above details should be sufficient
   
   Note - This is different use case than airflow hooks as hooks will be 
beneficial if the running DAGs are trying to connect to some external data 
store, here we want the airflow components themselves to connect using custom 
cloud specific authentication
   
   ### Use case/motivation
   
   Provides an ability to the clients of airflow to use Custom Authentication 
schemes while connecting to appropriate backend deta stores
   
   ### Related issues
   
   _No response_
   
   ### Are you willing to submit a PR?
   
   - [ ] 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]

Reply via email to