add templated policies for common acl targets with read and write verb

[n-marton]

Description

Since templated policies are compiled into the binary, it is easier just to add each common acl target with a read and a write template, that way it is easier to put together combinations on role or token level, rather than making more and more combinations into compiled.

PR Checklist

• [X] updated test coverage
• [ ] external facing docs updated
• [ ] appropriate backport labels added
• [X] not a security concern

[jkirschner-hashicorp]

Hi @n-marton,

This looks very interesting - thank you for proposing this contribution!

To help me better understand, can you share an example scenario with before/after that shows the importance/benefits of this change?

For some context, the original (long removed) ACL system didn't have ACL policies or roles. It just had ACL tokens. We found that led to a lot of access control sprawl because there was no re-usable access control ruleset construct (e.g., update 1 common policy for devs, all devs get their access updated). That's why the current system introduced ACL policies (and roles). I'm concerned that this PR opens the door for access control sprawl by avoiding a shared policy construct (the same problem we had with the original ACL system).

[n-marton]

hey @jkirschner-hashicorp

I don't fully understand the concern because this does not force policy changes on any existing policy or policy template.

To give an example why adding the basic building blocks is useful, lets say you have a fleet of servers and you are doing quite strict ACL management so you have policies like the following:

ID:           c9f3555d-3147-46db-bd84-e0ccac8756ca
Name:         policy_node1
Datacenters:
Rules:
    node "node1" {
      policy = "write"
    }

    service "service1" {
      policy = "write"
    }

    service "service2" {
      policy = "write"
    }

ID:           d32b2d02-fe22-4a02-a0c7-2ea2ca8e74f1
Name:         policy_node2
Datacenters:
Rules:
    node "node2" {
      policy = "write"
    }

    service "service1" {
      policy = "write"
    }

    service "service3" {
      policy = "write"
    }

So you have to generate a different policy for each entity you have.

However if you have templated policies for each building block, you can just do it on role/token side, like the following.

ID:           a13b7b4e-0119-3942-5476-67751b34d237
Name:         node1
Templated Policies:
   builtin/node-write
      Name: node1
      Datacenters: all
   builtin/service-write
      Name: service1
      Datacenters: all
   builtin/service-write
      Name: service2
      Datacenters: all

ID:           e73db97b-cfc9-4712-92a7-953f858e1771
Name:         node2
Templated Policies:
   builtin/node-write
      Name: node2
      Datacenters: all
   builtin/service-write
      Name: service1
      Datacenters: all
   builtin/service-write
      Name: service3
      Datacenters: all

Since you have to configure a role or a token anyway, it is much nicer and simpler to only configure those with templated policies than generating an individual policy per entity.

In this pull request I am only trying to add the basic acl objects, so configuring any combination of acl rules would not require additional pull requests and consul recompilations. Basically these policy templates are the smallest Lego building blocks, and anyone can build any combinations with them.

[n-marton]

@jkirschner-hashicorp any pointers wether this should go anywhere or not?

[Tyrael]

@jkirschner-hashicorp any updates?

[Tyrael]

cc @roncodingenthusiast you worked on these parts the most and approved previous contributions to templated policies, maybe you could help us moving this forward!

[Tyrael]

bump

[jkirschner-hashicorp]

Hi @n-marton,

Thank you for the thoughtful reply. I've discussed this with the team and wanted to follow up.

In short, we acknowledge that there's an underlying need here that remains unresolved, but we don't support this particular approach to addressing that need.

Details

Templated policies were intended to enable users to cover all authorization use cases with a very small number of authorization rulesets, to prevent policy sprawl. Where the structure of the authorization rules are the same, differing only on some variable(s) such as node or service name(s), a single "templated policy" could be used. If you ever need to update the rules, you can update that single "templated policy" and it applies everywhere.

In the example you provided, you could potentially have a templated policy named "node-locked-services" that accepts:

• A node name (to grant node:write on that node name)
• An array of service names (to grant service:write on those service names)

Currently, Consul only supports built-in templated policies. We will consider adding user-defined templated policies in the future, so that you could:

1. Achieve your goal of avoiding "generating an individual policy per entity"
2. Ensuring maintainability / avoiding policy sprawl by just having one (user-defined) templated policy for that particular use case

The approach in this PR goes against objective 2 above. It would cause each token to have rules directly applied. If you had 1000 tokens that should have the same pattern of authorization rules, and you ever needed to update that pattern, you'd have to correctly identify and update all 1000 tokens. That's a pattern we intentionally moved away from in the original ACL system based on the challenges it created for users.

We want to retain a level of indirection between tokens and authorization rules (e.g. templated policies), so that you can have all 1000 tokens point to 1 shared thing that defines the authorization rules. That greatly simplifies maintenance / review / auditing, especially if you're very focused on enforcing least-privilege access.

The Consul team can open a Github issue for user-defined templated policies and track interest and use cases there.

CC @rboyer , @blake

[n-marton]

hey @jkirschner-hashicorp

first, thanks for getting back

I don't really get the argument about avoiding policy sprawl, this PR in it self would make every future PR unnecessary. You have a certain amount of resources, and basically for actions, if you provide a templated policy for each resource with each action type, then everybody can build any combinations from those on role or token level.

So if userA comes that they need a templated policy covering resourceTypeX and resourceTypeZ you would need to create a templated policy with those two resource types, however if already have separate templated policies for both, you can just attach each of those to a token and role and no need to compile yet an other policy.

[github-actions[bot]]

This pull request has been automatically flagged for inactivity because it has not been acted upon in the last 60 days. It will be closed if no new activity occurs in the next 30 days. Please feel free to re-open to resurrect the change if you feel this has happened by mistake. Thank you for your contributions.

[Tyrael]

any update here?

[github-actions[bot]]

This pull request has been automatically flagged for inactivity because it has not been acted upon in the last 60 days. It will be closed if no new activity occurs in the next 30 days. Please feel free to re-open to resurrect the change if you feel this has happened by mistake. Thank you for your contributions.

[github-actions[bot]]

Closing due to inactivity. If you feel this was a mistake or you wish to re-open at any time in the future, please leave a comment and it will be re-surfaced for the maintainers to review.