We need a way to create a policy that grants privileges to a machine identity to read all secrets in a directory including imported ones and ones that include references, regardless of whether the identity has read privileges for the imported or referenced secrets. I think I asked about this a year ago when I was at a different company, but now I really have a need for it. Until now I've gotten around this by avoiding machine identities and just using secret syncs, which basically have the the same effect in that I can use them to give a resource access to an directory of secrets that may have imports and references, without also explicitly granting the resource access to the import and reference sources. However, now I want to use machine identities and so I'm running into this problem. The reason it's not enough to just grant the machine identity explicit privileges for any imported or referenced source is that we use a lot of imports and references, and I know some developer at some point is going to use a reference without remembering to also grant all our machine identities access to the reference first. When that happens our production servers, which are wrapped in

infisical run --

, will irrecoverably error on start, taking down production. Since our machine identities will only have view access for secrets, there's no risk that that a compromised machine identity can exfill secrets outside of its permitted scope by creating secrets that reference other secrets. So I don't see any reason why we woudn't want granting a machine identity view privileges on a directory to also grant it view privileges for imported and referenced secrets.

Sorry to leave you hanging Akio! Let me take this to the team and get back to you.

Thank you!

Hello again! We discussed it internally and unfortunately this isn't something we're going to support right now. The approach needed to make imports/references resolve transparently for machine identities would require bypassing our source-specific permission checks, which goes against our current permission model design. We'd rather not introduce that pattern at this point. That said, we appreciate you flagging it and it's on our radar if we revisit how permissions work in this area down the line. For now, secret syncs are still the best path forward here.

Damn, that's frustrating. Secret syncs don't really work well in this case for us. Are there any other solutions that could help here? Otherwise we'll probably end up granting our machine identities broad access, which is sadly less secure for us.

Hey Akio, We discussed this internally and unfortunately it's not something we're going to move forward with. The concern on our end is that a permission which changes how other permission checks resolve adds complexity to the permission model that we want to avoid. We hear you on the pain point though, and it's on our radar if we find a cleaner way to approach it down the line. Appreciate you pushing on it.

Got it. I think I thought of a solution that might work already without you having to add something. I should be able to set up an Infisical sync (https://infisical.com/docs/integrations/secret-syncs/external-infisical) to sync one directory (call it

a/

) that uses references into another directory (call it

b/

). Then I can give the machine identity permission for

b/

, and not worry about it having permission for any of the secrets

a/

references. Do you see any problems with this?

Are you syncing from one instance of Infisical to another instance? Syncing Infisical-->Infisical will not work within the same instance unfortunately.

Ugh, no. It would be within the same instance. Any chance you could enable it to work within the same instance?