Your company has a user pool, you sign a BAA or start working with a partner company that has their user pool. Instead of creating slack accounts in both you can share external slack rooms that only people that are invited in/from their respective orgs can join without having to co-mingle employee user pools.
But why would external partners want to look at your code? I guess if you're also integrating with them? But generally you just give them repo access instead. For Slack, it's different as messaging is a core feature to collaborate between different people in different companies, but looking at code is a very specific use case.
Not sure, I was only answering in regards as to what Slack shared rooms brings to the table for companies in the form of letting Project Managers/Account Managers have direct line of contact with clients.
Code wise I guess you can could be working with any agency or contractors and you could collab on PR reviews? No idea to be honest.
I'll reply, even though I don't like the tone the first sentance sets :)
I'm not sure exactly what parts of the comment are about secrets rather than how infrastructure should be done, but I see that secrets and configuration have very different lifetimes so they should be provisioned separately. The config can for example be in the git if it's free of secrets.
Secrets are provisioned at runtime, while config is build time.
`secretspec.toml` is in the version control and it tells you all about what's going to happen at runtime.
I'm not advocating that different locations of secrets IS something we want, but rather it IS the sad state of reality.
By having a secrets specification we can start working towards a future that will consolidate these providers and allow teams to centralize it if needed, by having simple means of migrating from a mess into a central system.
I'm assuming that the PaaS/IaaS providers already have solutions for secrets. So a new centralized system may help with just dev and DIY bare metal?
But the centralized method, as in secretspec, not everyone will accept reading secrets in environment variables, as is also done with the 1password cli run command [1]. They also may need to be injected as files or less secure command line parameters. In the Kubernetes world one solution the is External Secrets Operator [2]. Secrets may also be pulled from an API as well from the cloud host. I won't comment on how that works in k8s.
To note, the reason for reading from file handles is so that the app can watch for changes and reload, e.g., key/token rotations without restarting the server.
But what could be useful to some developers is a secretspec inject subcommand (the universal version of the op inject command). I use op inject / dotenvy with Rust apps -- pretty easy to manage and share credentials. Previously I had something similiar written in Rust that also handled things like base64 / percent-encoding transforms.
If you aren't tied to Rust, probably could just fork external-secrets and get all the provider code for free.
lastpass provide a cli that as far as I've seen serves all migration needs so I haven't seen any need to ever touch the service with a ten foot pole otherwise.
https://github.com/cachix/cloud.devenv.sh