[Design] What is the user model for defining what plugin/extension can do?

[peternied]

User Story

As a cluster administrator, I am able to explicitly grant and revoke permissions to extensions in order for extensions to access data, resources, and APIs.

Acceptance criteria

• How should granular should permissions grants be?
• Should there be difference between plugins and extensions
• Can we build more advanced 'level 2' controls that make larger enterprise management easier over time?

[peternied]

Proposal use fine grain permissions for initial release, expand to L2 objects over time.

There was a discussion of scopes [1] being a mechanism to express the permissions available to extensions. I would call this a 'level 2' control, as they are very effective to describe broader scenarios, but we might need to shuffle them to get granularity right in this new ecosystem.

I'd suggest we construct a singular permissions language that is universal usable to express fine grain control and enforceable, this can be used to initially ship extensions features, sharing the permissions language between users and any other identity. Then we can add 'level 2' mechanisms like scopes, or action groups as exist in the security plugin that would work in concert with the lower level system.

• [1] Scopes in slack https://api.slack.com/scopes

[peternied]

FYI @dblock @jimishs I believe you both had opinions about how this is constructed, I'd love your thoughts

[dblock]

At a high level I think we need a way to limit the scope (paf.) of actions an extension can make. For example, a tokenizer does not ever need to read or write data to an index. I don't know what's the best way to express that, but that's what I am after.

[cwperks]

I think this can be accomplished by treating extensions as subjects and defining permission grants to the extension in a similar manner as a cluster admin would to any other user. This gives cluster admins the same ability to express permissions to an extension that they would a user.

When an extension performs a request against a cluster, the extension will send a JWT in the header of a request that Identity can use to identify the user initiating the request and the extension it originates from. When performing a privilege evaluation on the request, the request will need to be both allowed for the extension AND for the user.

Some additional items for consideration is that I think extensions will need to have restrictions by default, like restricting the extension's ability to perform any action on a system index. There could be a reserved ("prescribed") set of permissions for extensions of different categories in an effort to make it easier to configure.