potiuk commented on issue #57428:
URL: https://github.com/apache/airflow/issues/57428#issuecomment-3478074869

   > We definitely should include an admin check. But I'm wary about a default 
to show passwords, I think requiring manual action to do a less secure action 
is a good thing.
   
   Just to write it also here - my strong opinion here is that this is NOT what 
we agreed to as part of our security model. If we are to allow **any** remote 
user to see the content of sensitive values over the API (whether it's export 
API or any other) - we will have to change our agreed model. Previously people 
(@ashb particularly) were very strong that making such sensitive information 
via API is not a good idea. We clarified it in the model, implemented specific 
changes to always mask such sensitive values and handle "write-only" model for 
such sensitive data (i.e. no remote user should be able to read stored 
sensiitive data). 
   
   In Airflow 2 we had different philosophy - Airflow API users with "edit" 
capability could see that password. This has been changed by @ashb and 
@pierrejeambrun's implementation  - but it has not been captured as a model 
change, and in Airflow 3.0.3 we implemented a change that revealed those 
passwords (fixing overriding of passwords when editing connection) and that 
caused a strong push-back from @ashb and discussion in the security team that 
led to changing it in 3.0.4 to mask all passwords, updating our security model 
to describe it and issuing this advisory to our users: 
https://www.cvedetails.com/cve/CVE-2025-54831/ 
   
   I think it's a good idea - before any security relatead change is discussed 
to follow it in the way that we do not repeat the same mistake. Discuss it with 
security team first ([email protected]) after consulting a security 
model. Yes. We can change a security model if we agreee to it, but this is not 
something that should happen in "issue" or "pr" and certainly its something 
that should be discussed and agreed with the security team - because ultimately 
it's the security team that has to handle any violations of the security model 
agreed.
   
   My current proposal - which I am going to propose tomorrow at the devlist 
which is a result of similar discussion in the security team is that we 
completely remove at least "export" functionality and only allow export by 
local CLI user - not by remote API user.  But I am open to a discussion and 
**devlist** agreement if we decide to change the model and allow admin user to 
do it (however we do not have a dedicated "admin" capabilty now - currently we 
have predefined set of roles and "Admin" user is **just** one of the roles, so 
if we want to something like that we would likely need to add EXPORT capabilty 
and grant such capability to Admin user by default. But let's discuss it in the 
devlist tomorrow.
   
   


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