Granular matching for role labels, kubernetes_labels, etc

[programmerq]

What

Currently, if a role specifies multiple key value pairs in the labels or kubernetes_labels section, it will allow access only to clusters that match all the criteria. As far as I can tell, there is not currently a way to specify key/value pairs where any of the criteria match.

If you want to have it match any one of the label key/value pairs, then you must split it out into a role of its own.

It would be nice to have the ability to specify the behavior as AND (current) or optionally OR. AND is certainly the sane default behavior, but it can get unwieldy when you need to have OR type functionality and end up creating additional roles for each set of criteria.

How

Perhaps, a list of maps would be treated as an OR list of sets. (this particular syntax may be too confusing)

So

kubernetes_labels:
    foo: bar

would be equivalent to:

kubernetes_labels:
   - foo: bar

and this being in one role would be the same as having two separate roles:

kubernetes_labels:
    - foo: bar
      bing: baz
    - key: value
      env: prod

Why

Sometimes OR behavior is necessary when there are many labeling methods in use. Attaching all the necessary access for a given role is ideal without needing to split the role up into multiple roles.

Workaround

Split up a role. (can get unwieldy for a large number of matches)
gz#3987

gz#4161

[stevenGravy]

This would be a general ask for roles, to have multiple match ability for labels for all protocol types

[programmerq]

A more verbose explanation follows. Say I have the following three kubernetes clusters with the corresponding labels:

• kube1
  • team=qa
  • env=stage
• kube2
  • team=dev
  • env=stage
• kube3
  • team=qa
  • env=prod

I would like to write a single role that gives access to all three clusters.

If I write a role that has the following label section, the user would only see kube1 and kube3 but not kube2:

kubernetes_labels:
  team: qa

If I write one that has the following, then the user would see only kube1 and kube2, but not kube3:

kubernetes_labels:
  env: stage

If I write the following, then I see only kube2 but not kube1 nor kube3:

kubernetes_labels:
  team: qa
  env: stage

This seems to be due to the fact that teleport wants all the labels listed in kubernetes_labels to match. I don't see a way where I can specify that any of them should match.

My proposal to add the ability for kubernetes_labels to be a list of maps instead of just a map would be a way to get OR capabilities without making many changes to the syntax. It would need to be documented very well, and other implementations to get the same functionality would be appreciated.

For use cases where there may be five or six conditions that need to be evaluated as an OR type condition, this can artificially inflate the necessary number of roles that need to exist in the system and it becomes unwieldy.

[knisbet]

Sorry, helicoptering in a bit, but I do want to note that the proposed configuration could lead to lots of footguns.

kubernetes_labels:
    - foo: bar
      env: prod

vs

kubernetes_labels:
    - foo: bar
    - env: prod

That very subtle difference has a completely different meaning.

[programmerq]

@knisbet yes, I agree that my specific proposed syntax could be problematic. The functionality is the heart of the request and the specific syntax can be altered. I'm happy to edit the original description to make the "how would you do it" less specific.

[klizhentas]

Our idea is to support or matching for labels, for example:

kubernetes_labels:
   or:
       - foo: bar
       - env: prod

[programmerq]

Editing the description to make it be not exclusive to kubernetes labels since we've had interest for other role lists per @stevenGravy's comment.

[zmb3]

See also #4468

[zmb3]

See also #9441 - it looks like roletester interprets this incorrectly.

[codersofthedark]

+1. we need this badly. We have to maintain too many subroles because of this.

[russjones]

We won't be able to address this in Q3 but will discuss potentially addressing this in Q4.

[klizhentas]

Here @nklaassen we can use expression syntax (and/or) isolated to labels that will cover a lot for us

[nklaassen]

This is addressed by label expressions released in 13.1.1

For example you can now write:

kubernetes_labels_expression: |
  labels["foo"] == "bar" || labels["env"] == "prod"