Hi All, I’ve noticed that we are still implementing new features or are doing refactoring of CLI commands that directly interface with the database instead of using the abstractions that should be made available from the API specification. Why is this an issue? The CLI is used by arbitrary user to interface with Airflow operations. Airflow relies on the database to be its single source of truth. A user that is able to read the configuration of Airflow is currently able to manipulate the database. The CLI requires database access hence the information to deal with the database is in the configuration file. To improve security the CLI should use a rest API which allows for proper authn/authz and segregation of duties.
In the past I have introduced the experimental API with a “local_client” and “json_client” implementation. The local_client still allows for direct database access and its only function is to be there during the transition period to have the full rest api available. After that it should be deprecated and removed. My suggestion is to disallow any new functionality in the CLI that directly relies on “airflow.utils.session” and only allow new functionality to go through the API client. For now that would mean 2 implementations: local and json. Of course refactoring the current state should be on the list in order to remove the “local_client”. The API client should be available to other packages as well. So maybe we should package the cli and client api implementations into “airflow-client”. What are your thoughts? Thanks Bolke
