Expanded Role format

[kontsevoy]

Role 3.0 Spec

kind: role
version: v2
metadata:
  description: "This role is the example for 2.3"
  name: "developer"
spec:
  # this is for misc options like "agent_forwarding" or "notty". 
  # Only agent forwarding option and session TTL is implemented currently.
  options: 
      agent_forwarding: "yes"
      allow_tty: "no"
      max_session_ttl: 8h0m0s
  allow:
      logins: ["dev", "ops"]       # mandatory!
      namespaces: ["foo", "bar"]   # ["*"] if not specified
      node_labels: 
          env: "staging"           # by default "*": "*"
      rules:                       # by default {resources: ["*"], verbs: ["*"]} (everything is allowed)
          - resources: ["sessions"]
            verbs: ["read"]
          - resources: ["configuration"]
            verbs: ["read", "write"]
          - resources: ["trusted_clusters"]
            verbs: ["read", "write"]
      system_resources:
        tunnel: ["read", "write"]
        node: ["read"]
  deny:
      namespaces: ["bar"]          # [] if not specified
      logins: ["dev", "ops"]       # [] if not specified
      node_labels:                 # empty if not specified
          - "env": "staging"
      rules:                       # by default empty (nothing is denied)
          - resources: ["configuration"]
            verbs: ["write"]

Notes:

• Role checker must look into "deny" section first. First match of any "deny" rule immediately leads to "access denied" without even looking at "allow" section.
• RBAC documentation must clearly reflect how this works.

Implementation Notes

• Resources in RoleV2 are called SystemResources in RoleV3.
• Deny rules are checked before allow rules. A single deny rule will prevent access.
• Rules are checked first, if you get denied by a rule, then we check resources. Note in the above situation a deny rule can be overruled by a allow system resource.
• Options has been added to hold settings like max session life, agent forwarding, etc.

[klizhentas]

@russjones don't forget to update version of the resource to v3 then

[russjones]

After the discussion yesterday, under the new proposed Role format the RoleCondition will look something like the following.

allow:
  logins: ["dev", "ops"]
  namespaces: ["foo", "bar"]
  node_labels: 
    env: "staging"
  rules:
    - resources: ["sessions"]
      verbs: ["read"]
    - resources: ["configuration"]
      verbs: ["read", "write"]
    - resources: ["trusted_clusters"]
      verbs: ["read", "write"]
  resources:
    tunnel: ["read", "write"]
    node: ["read"]

The rules section will be evaluated first then the resources section.

I do think we need to rename resources under rules to avoid confusion. Some candidates: articles, elements, components.

[klizhentas]

@russjones @kontsevoy to make it clear, resources will not be user facing property, will be used internally.

[russjones]

@klizhentas @kontsevoy Another item it's worth getting clarity on, at the moment in CheckAccessToServer I have implemented deny rules as OR. Meaning if you hit the deny on login or namespace or label you get denied access. Take a look:

https://github.com/gravitational/teleport/blob/095e270b7020004bb467e8114bd183b90a6ee616/lib/services/role.go#L1004-L1016
https://github.com/gravitational/teleport/blob/095e270b7020004bb467e8114bd183b90a6ee616/lib/services/role.go#L1018-L1032

[kontsevoy]

@russjones correct: a single deny trigger automatically denies access.

[russjones]

Implemented in #1092