dabla commented on issue #57428: URL: https://github.com/apache/airflow/issues/57428#issuecomment-3531174870
> > 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 (or at the very least clarify) in our agreed model. Previously people ([@ashb](https://github.com/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](https://github.com/ashb) and [@pierrejeambrun](https://github.com/pierrejeambrun)'s implementation in 3.0 - 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](https://github.com/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]](mailto:[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. I agree with removal of export functionality in UI, as it doesn't make sense to export masked secrets in variables (or connections) anyways and this is indeed a possible vulnerability. -- 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]
