[ENG-152] Secret dependency

[zifeo]

Feature description

Ability to sync or inherit secrets between projects.

Why would it be useful?

Sometimes "global" secrets (think of a certificate signing some apps) must be shared between projects (think app A and app B signed by the same certificate). Currently the CI cannot use a service account to access 2 projects, thus a way to embedded those global secrets and keep them in sync is important.

Additional context

An alternativement implement could be to have service account like a user and use a secret aggregators like lade.

_{From SyncLinear.com | ENG-152}

[Grraahaam]

Hey @zifeo !

Might be related : https://infisical.com/docs/documentation/platform/secret-reference#referencing-syntax
And discussed here : #32

Would that fit to your current use case?

Cheers

[zifeo]

@Grraahaam does that support referring a secret into another project?

[Grraahaam]

@Grraahaam does that support referring a secret into another project?

TL;DR I don't think it can refers secret from another "project", but it can from an other "folder" 🤷🏽‍♂️

Then it'll depend on how you've structured you're secrets. Take a look at the syntax its pretty straightforward :

• https://infisical.com/docs/documentation/platform/secret-reference#syntax

So if you want sub-services to be able to use referenced secrets you'll have to structure it like (in a single project tho) :

• / (global secrets)
• /micro-service-a (sub-service, can get referenced secrets from /)
• /micro-service-x (sub-service, can get referenced secrets from /)
• /micro-service-x/frontend (sub-service, can get referenced secrets from / and /micro-service-x)

Your PR is about "project" secrets referencing, so it is different (while providing the same kind of feature at the "folder" level)

I just wanted to highlight the fact that a similar case have already been discussed earlier, if ever it could help people bumping into this issue ✌️

Cheers 🤙🏽

[zifeo]

@Grraahaam thanks, however we sadly need different projects as team members might not all have the same permissions (yet still all the access to the shared secrets). Happy to close in favour of the previous request if the use case is equivalent.

[ohmydevops]

Same here, I used another approach for this problem and it works.

[zifeo]

@ohmydevops What approach did you use?

[Emiliaaah]

In our environment this would be a pretty critical feature. Having the option to reference things like smtp credentials in multiple projects would make managing them all a lot easier, since you wouldn't have to update them for every project. This would stop the need for changing the credentials in 10 different projects, since you can just update them once.

Which also gives you better overview, since you no longer have to figure out which one is the newest version.

[drollinger]

Adding a +1 to this request. It seems like this has been something that has come up several times. In our case we have several projects with different teams working on different projects. They may want to set up their environments differently based on their workflow but we may share a secret. The mono-project doesn't work great since the projects are very different and they would have to share the same environments setup. It would be nice to have some central project or vault so we only need to update secrets in one place. For us however, it's a nice-to-have since updating secrets in more than one place isn't too difficult and with the upcoming improvements to search, I think we'll be able to find all the places to update secrets easily. Maybe some sort of Pro/Enterprise feature to link the secret value to a central admin run vault or something would solve any situations I could think of.

[clarksandholtz]

This feels like a majorly important feature. Would LOVE to be able to make a project that is a composition of sets of secrets plus its own set of secrets.

To simplify implementation and avoid having to worry about project dependency cycles, it would be nice to introduce a new concept of some sort of set of secrets that projects can choose to include.

[GeorgeBark]

+1 to this request. Is this something that is being considered? Thanks

[Distortedlogic]

+1

[a-ricci848]

+1