Speaking from personal experience - we use 1password at Airflow. Not super happy with it after the changes mentioned - yes - we shared the passwords there a long time ago, we have a few PMC members who have access to those (not all PMC members have it) and we have not had a need to add anyone new since, but if sharing became problematic, we would likely want to introduce something else - possibly similar to some other teams utilising the GPG keys we have and storing encrypted passwords in SVN is a good idea that might have some good tooling around (I have not explored that one) - keeping encrypted passwords in Version Control System by utilising public GPG keys is generally a solved and often used mechanism with good tooling, I just have not looked at the particularities of SVN tooling (but I think Volkan could explain their setup - discussed recently at slack).
I am not sure though if guidance/recommendation from the security team is something that is appropriate here - i don't think we should give recommendations for particular 3rd-party tools. While it is important to keep passwords secure and encrypted basically using end-user encryption, where you encrypt and share the passwords using your personal key and the provider does not have access to it and has serious level of public 3rd-party audit (which I believe all popular password managers have and publish) you can rely on, it's likely up to the PMC members to make the right choice. That would be my general rule for those. We have to remember that security is also a matter of convenience, not only about technical viability of some solutions, so whatever does not expose the passwords to 3rd-party and is convenient for the PMC members, should be fine. Also while those secrets we are talking about should be kept secure, you have to remember that they are temporary, and there is not much "vendor lock-in" in place. I personally changed my password manager several times in my life and it was always easy - I imagine with the PMC level, there are literally a handful of secrets to be kept this way, so nothing that could be changed overnight. There are literally 5 secrets we keep in Airflow. Most of them are about social media accounts and one about AWS accounts we use exclusively for CI / execution/ publishing development documentation - nothing "user" facing. And due to the nature of those secrets, there is no need to archive and keep history of them, so there are no particular requirements from that side. There should be really very few things that **should** be that sensitive that it would require foundation-level infrastructure (secrets required for releasing software) should be fully personally identifiable and attributable (that's what our GPG keys do) and individual PMC members should be responsible for keeping them safe, or managed infrastructure - and those should not be kept elsewhere IMHO. You also should look at 2FA for anything that is **really** sensitive and that would be a general guidance to strive for having 2FA authentication for services that are really important. I hope that is a useful "guidance" - note that's my personal view on the matter, not "official" statement of the security committee, though. I wonder what others think. J. On Wed, Mar 27, 2024 at 6:13 PM Bill Cole <[email protected]> wrote: > On 2024-03-27 at 02:43:11 UTC-0400 (Wed, 27 Mar 2024 15:43:11 +0900) > Bryan Ellis <[email protected]> > is rumored to have said: > > > Could the security team provide guidance on whether utilizing third-party > > services like 1Password for password management is acceptable? > > 1Password specifically is problematic because they no longer support any > mechanism for sharing vaults other than through their proprietary service > and using their proprietary client. > > An alternative would be to use an open-source password manager like > Bitwarden or just a vault format like KDBX or PasswordSafe that could be > shared via ASF infrastructure using ASF access controls. > > > I've noticed several projects already adopting it, but I couldn't find > any > > documentation clarifying whether third-party services are deemed > acceptable > > or not. > > I am a contributor to the ASF SpamAssassin project, which relies on some > donated commercial services, most visibly DNS for spamassassin.org but > also non-trivial performance feedback and public data mirroring. I don't > believe that has ever been deemed a problem, although they do make us > dependent on a small group of commercial partners, in aggregate (i.e. not > on a single service provider but on some competent set of them.) > > Being reliant on a single specific third party for access control to > project resources seems somewhat different qualitatively. However, I don't > believe there's any explicit ASF-wide policy on whether such a service can > be used. > > > In our project scenario, we manage a handful of accounts, most of which > > require OTP (one-time passwords). Leveraging password managers like > > 1Password enables us to share OTPs easily. Without a password manager, in > > some cases, I would have to wait for an individual to log in to fetch the > > OTP from their Authenticator app or even from a text message to their > > phone. This could become problematic if the person becomes inactive or > goes > > on vacation. > > Having used 1Password myself until their latest rent-seeking major update, > I do not think it is the best choice of a PM for an ASF project, but I also > recognize my bias and think that this needs to be a project-level choice > so: you do you. PMC members have a better understanding of their specific > project needs and risks than any central policy on 3rd-party services could > address. > > > The access to the password manager would only be given to Project > > Management Committee (PMC) members who requested it. > > > > I've created a 1Password Team account but am currently waiting to see > what > > the security team's stance is on using such services before I upload any > > information. > > I should note that I speak only for myself as an interested ASF member and > contributor. I have no security role at the foundation level. Ignore me > freely.
