Role UX cleanup part 1: resources

[kontsevoy]

Problem

Teleport roles currently do not have a nice UX. Lets start with the documentation:
http://gravitational.com/teleport/docs/2.0/enterprise/#rbac

The "Roles" chapter quickly explains what a role is and then switches to "resources", where a bunch of unknown things are dumped on the reader. Then (not implemented yet) namespaces are mentioned. Then we show a role example which actually does not mention resources and the chapter ends.

This needs to be cleaned up.

Proposal

Resources

Remove resources from the Role definition completely. That's just a list of very low level Teleport data structures. What purpose does it serve to mention them in a role? Trying to use them makes RBAC very hard to reason about, for example what does it even mean to have "write" access to a "proxy"?

This should be step 1 towards improving RBAC usability. Step 2 would be to add higher-lever permissions, like "audit" (i.e. ability to view other people's recorded sessions, see #924 or #928 for example), etc.

Namespaces

Folks are trying (and failing) to use namespaces right now because they are not exposed properly to configuration / CLI. Proposal is to remove all traces of namespaces from 2.2.1 (i.e. in docs and configs). They will be properly re-introduced in 2.3

[russjones]

@kontsevoy Some initial thoughts:

Enterprise

Replace resources with permissions that operate on Teleport level concepts. Internally, permissions will simply wrap one or more resources. Initially we support the following permissions:

• trusted_cluster: This allows a user to configure settings for a Trusted Cluster at runtime. For example, a user with the trusted_cluster permission will be able to add, remove, or modify a Trusted Cluster.
• authentication: This allows a user to configure settings for cluster authentication at runtime. For example, this allows a user to switch authentication methods like local+otp to external+oidc.
• roles: This allows a user to add, remove, and update roles at runtime as well as assign roles to users. For example, you can create a role and assign a user to that role.
• session_viewing: ???

Values for the above three roles initially can be either allow or deny. allow maps to [ read, write ] and deny maps to [ read ].

Below is an example of how the new permissions will map to the old resources:

kind: role                              kind: role
version: v2                             version: v2
metadata:                               metadata:
  name: admin                             name: admin
                                          namespace: default
spec:                                   spec:
  logins: "{{index . logins}}"            logins: [ login1, login2, ..., loginN ]
  max_session_ttl: "90h0m0s"              max_session_ttl: "90h0m0s"
  node_labels:                            node_labels:
    "*": "*"                                "*": "*"
  permissions:                    ->      resources:
    trusted_cluster: allow                  tunnel: [ read, write ]
                                            trusted_cluster: [ read, write ]
                                            cert_authority: [ read, write ]
    authentication: deny                    cluster_auth_preference: [ read ]
                                            oidc: [ read ]
                                            saml: [ read ]
                                            universal_second_factor: [ read ] 
    role: allow                             role: [ read, write ]
                                            user: [ read, write ]
    session_viewing: ???                    ???

Built-in roles

Two build-in roles are always included in Enterprise. These roles can not be modified or removed by Enterprise users because they are used as defaults by Enterprise command line tools like tctl.

kind: role                              kind: role
version: v2                             version: v2
metadata:                               metadata:
  name: admin                             name: admin
                                          namespace: default
spec:                                   spec:
  logins: {{index . logins}}              logins: [ login1, login2, ..., loginN ]
  max_session_ttl: "90h0m0s"              max_session_ttl: "90h0m0s"
  node_labels:                            node_labels:
    "*": "*"                                "*": "*"
  permissions:                    ->      resources:
    trusted_cluster: allow                  tunnel: [ read, write ]
                                            cert_authority: [ read, write ]
                                            trusted_cluster: [ read, write ]
    authentication: allow                   cluster_auth_preference: [ read, write ]
                                            universal_second_factor: [ read, write ]
                                            oidc: [ read, write ]
                                            saml: [ read, write ]
    role: allow                             role: [ read, write ]
    session_viewing: ???                    ???

kind: role                            kind: role
version: v2                           version: v2
metadata:                             metadata:
  name: user                            name: user
                                        namespace: default
spec:                                 spec:
  logins: {{index . logins}}    ->      logins: [ login1, login2, ..., loginN ]
  max_session_ttl: "90h0m0s"            max_session_ttl: "90h0m0s"
  node_labels:                          node_labels:
    "*": "*"                              "*": "*"
                                        resources:
                                          session: [ read ]
                                          role: [ read ]
                                          node: [ read ] 
                                          auth_server: [ read ]
                                          tunnel: [ read ]
                                          cert_authority: [ read ]

Command-line changes

# by default, "tctl users add" creates users with role "user"
$ tctl users add rjones

# however, you can specify if you want a user with role "admin"
# or "user" by passing in the "--role" flag.
$ tctl users add --role=admin rjones rjones
$ tctl users add --role=user rjones rjones

Enterprise users continue to be able to add and delete roles additional roles with the following commands:

$ tctl create -f {role file}
$ tctl rm {role name}

When viewing roles and users, we will make the following changes to tctl.

$ tctl get roles
Role            Allowed to login as     Node Labels     Permissions
----            -------------------     -----------     -----------
admin           {{index . logins}}      <all nodes>     trusted_cluster:allow, authentication:allow, role:allow, session_viewing:???
user            {{index . logins}}      cluster=two     <none>
tc-admin        {{index . logins}}      <all nodes>     trusted_cluster:allow, authentication:deny, role:deny, session_viewing:???

$ tctl get users
User       Role            Created By
----       -----           ----------
rjones     admin           system
jsmith     user            admin

Teleport

Open source Teleport will also have the two hardcoded roles admin and user which can not be modified just like with Enterprise.

Command-line changes

When adding users, we need to add the ability to tctl to specify the role.

# by default, "tctl users add" creates users with role "user"
$ tctl users add rjones

# however, you can specify if you want a user with role "admin"
# or "user" by passing in the "--type" flag.
$ tctl users add --role=admin rjones rjones
$ tctl users add --role=user rjones rjones

When viewing roles and users, we will make the following changes to tctl.

$ tctl get roles
Role            Allowed to login as     Node Labels     Permissions
----            -------------------     -----------     -----------
admin           {{index . logins}}      <all nodes>     trusted_cluster:allow, authentication:allow, role:allow, session_viewing:???
user            {{index . logins}}      cluster=two     <none>

$ tctl get users
User       Role            Created By
----       -----           ----------
jsmith     user            system
rjones     admin           system

Open Questions

1. Should we introduce the concept of admin and user to open source Teleport? It might be simpler to simply have a single role for all Teleport users because the values the permissions update are not exposed in the Web UI like in Enterprise.
2. We'll need to inject values into fields like logins because they are different for each user.
3. Should we handle session viewing in this round, or address that at a later time? We should lay the groundwork for the design at least.
4. What values should these roles take. Initially we can support allow and deny, but how do we handle more complex situations like session viewing?

[alex-kovoy]

Since we also have a concept of 'permissions' in Telekube (only on UI level) it seems that our work here should be align with what we have in Telekube (or other way around). Please take a look at what we have in Telekube in regards to mapping between low-level resources and UI permissions.

And this talks about intent of the detach/attach methods.

Please ping me before we jump into implementation.

[alex-kovoy]

As for data structure, here is what we use in Enterprise and Telekube WEB UI. Do you think we can do something similar for a better code reuse?

name: test_rule
access:
  ssh:
 	logins: ['xxx']
  kubernetes:
	groups: ['xx']
  applications:
	full_access: false
  admin:
	enabled: false
  cluster:
	enabled: false
  license:
	enabled: false

If possible, I would avoid fields like 'meta' or 'version' and try to keep it simple.

[kontsevoy]

@alex-kovoy I looked at the links you have provided... Will discuss later.
Also, this ticket has moved to #1079