jscheffl commented on PR #62129:
URL: https://github.com/apache/airflow/pull/62129#issuecomment-3930121955

   > @jscheffl all valid concerns, I wonder what's the best way to handle it 
here.
   > 
   >     1. For upgrade paths, when people upgrade to the new version of this 
provider, the new code will try to create that secret and fail with a 403, will 
adding something like "you need to update your RBAC" in the scheduler logs be a 
good way to handle this?
   > 
   >     2. About remote clusters, unsure how to handle it. This will involve a 
remote cluster admin to grant some more permissions (specially in secure 
environments), so I wonder what's the best way forward there.
   > 
   > 
   > In such cases, maybe the best fallback would be to fallback to the legacy 
way (using CLI args) maybe using a flag or a new configuration to keep 
migration smooth and not break usage?
   > 
   > Any thoughts @jedcunningham @jscheffl @potiuk ?
   
   Regarding 2) I have no strong opinion. Just by the arguments... an automated 
fallback with logged warning might be the "nicest" and a security researcher 
then might complaint that such error might start dropping secrets to CLI. It 
might be a configurable fallback?
   
   Regarding 1) in theory could follow whatever we decide for (2)?


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