infisical
infisical copied to clipboard
Infisical
Add deeper organizational structure for secrets
Feature description
Some users have pointed out that our secrets right now are just grouped by environment and split into shared/personal. It would be awesome to have a more advanced organizational structure (e.g., you can put secrets into smaller groups). One idea that I had was to add tags (e.g., #mongo, #stripe, #auth, #encryption). Then people can choose to view secrets by these groups + we can make a more advanced search that allows users to filter by tags.
Feel free to propose any other ideas is anyone wants to take this issue :)
Why would it be useful?
This will just make it SO MUCH EASIER to navigate for people.
Additional context
This would require both frontend and backend
Will the tags be persistent between environments or will they be confined within environment?
For example:
In environment dev, I have MONGO_HOST, MONGO_USER and MONGO_PASSWORD and all of them under the group named Mongo Credentials with tag #mongo. Will I be able to see/access outside of dev?
That's a really good question! Maybe there is a button that says 'add this tag to all environments'. What do you think?
We generally need an easy way to inherit secrets from different environments.
Maybe there is a button that says 'add this tag to all environments'
It's can be convenient if you want to add to all environments but not if you just want to duplicate to another environment.
What about we just group the secrets? I mean like we can add button alongside + Add key saying + Create Group and drag and drop existing secrets inside of the group and also add + Add Key button to right side of the group which will add key inside of the group. With that we can also add Transfer to..., Duplicate to... and Make Shared/Personal with dropdown?
But to be able to do that we need to refactorr some of the backend API and logics.
We actually had drag and drop secrets at some point, and we decided to roll back to the static approach because of performance issues when you have 100+ drag and droppable secrets
Also, I think the groups would be great, but I'm afraid the interface will get very cluttered. How would you organize both groups and personal/shared secrets?
What is the purpose of Personal Secrets. I mean if developer is using Infisical to manage Secrets for it's projects, won't be the Personal Secrets eventually shown to the other people working on the project? Or those people who have access to production build? I'm bit confused with the division between Personal and Shared. If there is no major difference we can just combine them into one and make it grouping priority.
Personal secrets are used for secrets like DB_URL - because every developer has their own version of this secret
Oh, I get it now. If this the only usage of it rather than using Personal Secrets what about we change it to Override or something like that? With that it will be more understandable to new comers like me 😄. If we do that we don't need to add group to Override section so it will be better of UI/UX.
Yeah, that is a good idea, I think! Overrides are much more flexible actually! We would need to store both the actual secret and the override for each user, and then we would need to decide what secret to use on Frontend/CLI. I think that sounds great! And then we can organize secrets in groups. Indeed
I would love to able to tag secrets.
Another use case for this would be to add a tagSelector to the k8s operator. This would allow a more fine-tuned control about what secrets will be deployed by an InfisicalSecret on Kubernetes.
Currently there is no simple way to define which secrets are deployed in which namespace and that is a bit a bummer.
Yeah, that is a good idea, I think! Overrides are much more flexible actually! We would need to store both the actual secret and the override for each user, and then we would need to decide what secret to use on Frontend/CLI. I think that sounds great! And then we can organize secrets in groups. Indeed
On the frontend we could keep it like it is today (two lists on the project secret dashboard) or combine both list with a little badge on top of every secret keys that are overridden by the user (developer config), with the availability to quickly the the original values (like the top button to see all the secrets, there could be a global "see original secrets" button + on each secret entry), what do you think? 🤔
For the CLI, we could add a switch : e.g. infisical run --override -- docker-compose up -d or use the config file generated by infisical init by adding a line with override: true? 🤷🏽♂️
I would love to able to tag secrets.
Another use case for this would be to add a
tagSelectorto the k8s operator. This would allow a more fine-tuned control about what secrets will be deployed by anInfisicalSecreton Kubernetes.Currently there is no simple way to define which secrets are deployed in which namespace and that is a bit a bummer.
In our company (using Doppler so far), to fine-tune the secrets we have per NS or app we split them through different projects, since you can generate an access token for each project + config (environment), allowing you with some Helm/GitOps mechanism to easily scope secrets per app/ns.
And to avoid repeating ourselves, we use the cross-project reference feature (Doppler, but being discussed here : https://github.com/Infisical/infisical/issues/32), so we define the value one and then we apply it where we need it, and they get automatically updated if you change the original value ✌🏽
Tags could still be useful for devs or even projects a little too big, to sort/filter out secrets, let's gather more use cases to see the real impacts? 💡