Re: [DISCUSS] Proposal around the Injection of Task Execution Secrets

First pass done - especially around security aspects of it, Looks great. On Fri, Jun 14, 2024 at 2:55 PM Ash Berlin-Taylor wrote: > I’ve written up a lot more of the implementation details into an AIP > https://cwiki.apache.org/confluence/x/xgmTEg > > It’s still marked as Draft/Work In Progress

Re: [DISCUSS] Proposal around the Injection of Task Execution Secrets

I’ve written up a lot more of the implementation details into an AIP https://cwiki.apache.org/confluence/x/xgmTEg It’s still marked as Draft/Work In Progress for now as there are few details we know we need to cover before the doc is complete. (There was also some discussion in the dev call abo

Re: [DISCUSS] Proposal around the Injection of Task Execution Secrets

> IMHO - if we do not want to support DB access at all from workers, triggerrers and DAG file processors, we should replace the current "DB" bound interface with a new one specifically designed for this bi-directional direct communication Executor <-> Workers, That is exactly what I was thinking

Re: [DISCUSS] Proposal around the Injection of Task Execution Secrets

I added some comments here and I think there is one big thing that should be clarified when we get to "task isolation" - mainly dependance of it on AIP-44. The Internal gRPC API (AIP-44) was only designed in the way it was designed to allow using the same codebase to be used with/without DB. It's

[DISCUSS] Proposal around the Injection of Task Execution Secrets

Fellow Airflowers, I am following up on some of the proposed changes in the Airflow 3 proposal , where more information was requested by the community, specifically around the injection of Task Execution Secrets. Thi