Improved access control

[jon4hz]

Feature description

At the moment, the only option to prevent infisical to inject all secrets from an environment is to use the --tags option. This is useful when you want to make sure, that an application sees only certain secrets.
However that sort of access control is only on the client side and if your token gets leaked, a bad actor could still access all your secrets.
It would be great, if you could generate access tokens with limited scopes which can only access certain tags.

This sort of access control should also be available for the cloud integrations.

Why would it be useful?

In my option, this feature would greatly increase security. It allows using infisical with a least privilege principle by exposing only the secrets that are actually required.

[Grraahaam]

Hey!

That may help this issue as well : #243 (project/env/(tags) scope)

We could have some kind of "service accounts" which you'll be able to bind with given projects/envs/tags making it a secret package (only the one you'd like to share)? That's a bit how one of the main SecretOps solution on the market is doing, without the tags (so we still have something extra 💪🏽 ). What do you think?

We discussed about a similar integration with the k8s secret operator with @maidul98 some weeks ago, let me draw a suggestion :

Of course it's only a suggestion (and also just a draft), additional modals/pages might be required to set/manage those new permissions and access control

Service accounts are only here to provide access (write,read,...) through tokens to the different integrations, you won't be able to login in the web UI with them. I'm also thinking of using those service accounts to ease the developers' local setup, by providing all the secrets/conf they need through one single commands without having an account! Could be be useful in (open-source) projects to quickly setup a working environment ✌🏽

With the suggestion above, I don't see any breaking changes since the work will be focused on the front/backend I guess. Integrations (CLI, k8s, apps) will keep using the tokens the same way but will only get the secrets scoped by the configuration

[jon4hz]

That looks amazing! Service accounts as you described them would be even better that just scoped access tokens.

[dangtony98]

@jon4hz Currently, service tokens allow users to pull and inject all secrets from a given project and environment. Would it suffice to add a third field tags to service tokens to filter secrets by project, environment, and tags to be returned from the backend?

@Grraahaam Very cool! Is the concept of a service account similar to the concept of a service token but with broader scope here? It sounds like broader type of service token that can access multiple projects and environments and tags within them?

Also, the custom roles feature will definitely be coming next soon (just added it to the public roadmap).

[jon4hz]

Yeah, a third field to limit access tokens to certain tags would be a great improvement and cover a lot of use-cases.

I didn't have the need (at least not yet) to generate access tokens which have permission to more than one environment but I'm sure others might have that need and @Grraahaam's proposal would cover these. So having both options - limited access tokens and service accounts - would be amazing.

[Grraahaam]

@dangtony98 Indeed, service accounts (or whatever you want to call them in Infisical) behave like real users and can be managed as such IMO, the only difference is the use and the fact that it's not a real user (no login, no auth possible other than through tokens). And also the design, it'll be able to fetch and merge multiple projects' secrets at once (filtered by envs/tags) as you mentioned, and it may also be bound to multiple tokens (different uses, ttl, rotation, to be discussed)

---

Today's service tokens, AFAIK have a limited time-to-live (12 months max.) and that's a limitation IMO if you don't handle this implementation where it's used.. Otherwise it'd be great to add a tag field when creating such token, it'd help the user to scope the shared secrets if required, good idea!

How I see it is that service accounts may be the service tokens' evolution, and you could also add the possibility to create time-limited/ephemeral service accounts' tokens if you want to keep the current "Token expiry" feature

[jon4hz]

Since you already mentioned the TTL of service tokens, what do you think about adding an option to create tokens without expiry? Certainly it isn't best practice to use such tokens but I think it should be up to the user to decide.

[vmatsiiako]

@jon4hz indeed! there is an issue for that actually: #33

[akhilmhdh]

Closing this issue as Infisical has now granular permission system, service tokens and other security measures like ip whitelisting