Frustrations with .env File Handling and Environments in 1Password

Just registered to comment here, as I'm trying to transition to 1pass for managing my CI/CD + local env + personal passwords etc. 

Anyway, big agree with carsaig​ - this is a mess. For one project I have like 20 vaults, many service accounts, etc. It's not a great setup/management experience.

Environments in their current iteration seem kind of pointless? I can't reference vault items inside them, so again it results in duplication. The goal with all of this stuff should be single source of truth, so that updates and synchronization can be automated cleanly and easily.

Notes on env vars is also missing, which is an obvious thing that I'm surprised was missed. Comments in .env files is very normal.

Creating environment variables inside vaults feels clunky to begin with. Most of mine end up as notes. Having a dedicated "environment variable" item would make more sense. 

Splitting up environments from regular vault stuff seems like a huge disconnect. Why not just have an "Environment variable(s)" item in 1pass that can be created in vaults, and allow it to set comment, name, value for each field. That's all you need. Then we can use the existing permissions systems to manage everything. I have no idea why this was made as a separate feature in the way it is... You already have the structures in place, it doesn't need its own special area of the app like you have. 

Vaults are a poorly implemented concept right now - mainly for the reason carsaig​ indicates. It's like they're flat layered folders with permissions assigned to them. But there's no hierarchy. It's really messy. I think you guys need to just copy Google Drive's hierarchy system basically. Make "vaults" be folders. Let us nest them so we can organize things. Let us assign permissions at the folder level like Google Drive, using the same sort of inheritance system. This solves the wildcard problem he mentioned. Then you can assign SA's at any hierarchy level. The more you avoid doing this, the worse things will get. Then the product becomes a lot simpler really, you have folders, you have items, and environment variable files (.envs) are another type of item. Or you could have an individual environment variable too (in the same way you have notes + document, you can have env var vs env file). Env var can be note, var, value. Env file can be a collection of such. Simple. Then you can have "shortcuts" aka pointers to other items (like op://). 

Furthermore, I'm not sure if it's a bug or what, but right now I can't access or see service accounts in my 1pass client. I have to do it through the web portal. That's a big problem. In addition, you can't edit service account assignments once they're created (what vaults they access). That's also a very annoying limitation, and I don't understand why it needs to exist. If I have access to delete and create service accounts, I should be able to edit them too. If your 1pass is compromised, it's game over anyway. What's the security reason for this? An attacker gets access to your 1pass and removes or adds a vault to the service account? Removing a service account doesn't mean anything, because they could just delete the service account. Adding a vault... Well they already have access to the vault if they're able to create service accounts, so there's no difference here either. If they have access to this level of control it's game over regardless. Re-organizing my setup is something I've had to do multiple times already and it's REALLY annoying having to recreate the SA's every time. 

Anyway, I use 1pass for everything personal, and was hoping it would be the solution for all my dev as well - but if this isn't changed I doubt I'll stick with it. It's already cumbersome and it'll get more cumbersome as my infrastructure grows, without the features described above. Like carsaig​ said - massive opportunity for 1pass here if they get this right, but you should probably act soon on it because it's a competitive space and the timing is great for it right now when everyone is moving into LLMs and trying to set up automated secrets management pipelines.