Can't get OSS RBAC to work

[apiening]

I did a quick local teleport deployment with docker-compose based on the image quay.io/gravitational/teleport:6.0.0.
Based on the release notes for 6.0 there should be OSS RBAC support in this release (see https://github.com/gravitational/teleport/blob/master/rfd/0007-rbac-oss.md).

I have created a user with

docker-compose exec teleport tctl users add admin root

and after the user has been activated, I assigned the admin-role:

docker-compose exec teleport tctl users update admin --set-roles=admin

which was confirmed with the message admin has been updated with roles admin.

However, when I log into the teleport web interface, I can't manage users or assign roles to servers. I can't really see anything related to RBAC, not even the role what has been assigned to the user is shown in the profile.

I may have a complete wrong understanding how RBAC is implemented in the OSS version. However, I can't find any documentation on this topic.
Do I need to specifically enable RBAC functionality somehow?

[apiening]

I figured out that I can check the available roles with

docker-compose exec teleport tctl get roles

Here is the output I got:

kind: role
metadata:
  id: 123123123123123123123
  labels:
    migrate-v6.0: "true"
  name: admin
spec:
  allow:
    app_labels:
      '*': '*'
    db_labels:
      '*': '*'
    db_names:
    - '{{internal.db_names}}'
    db_users:
    - '{{internal.db_users}}'
    kubernetes_groups:
    - '{{internal.kubernetes_groups}}'
    kubernetes_labels:
      '*': '*'
    kubernetes_users:
    - '{{internal.kubernetes_users}}'
    logins:
    - '{{internal.logins}}'
    node_labels:
      '*': '*'
    rules:
    - resources:
      - event
      verbs:
      - list
      - read
    - resources:
      - session
      verbs:
      - list
      - read
  deny: {}
  options:
    cert_format: standard
    enhanced_recording:
    - command
    - network
    forward_agent: true
    max_session_ttl: 30h0m0s
    port_forwarding: true
version: v3

On the RBAC Documentation page (https://goteleport.com/teleport/docs/enterprise/ssh-rbac/) it says: By default there is always one role called admin which looks like this: followed by a YAML configuration.
Comparing the rules section from my role definition posted above, I noticed that there is something missing in the rules-section. In fact, there were no rules for the resources role and user defined, like they are in the example.

That's why I exported, edited and re-imported the roles with:

tctl get roles > updroles.yaml
vim updroles.yaml
tctl create -f updroles.yaml

After this, the rules-section shown by docker-compose exec teleport tctl get roles were the same like in the manual.

After logging out and back in, I was able to see the additional section Team in the navigation.

I guess that my role was not updated when I upgraded from Teleport 5.0 to Teleport 6.0.

[klizhentas]

Yes, thanks for writing it down. Our docs are a bit behind the product 6.0 update. Pre Teleport 6.0 OSS, all open source users were assigned built-in admin role. Our 6.0 migration kept this role, but lowered privileges, so all existing users won't become cluster admins after upgrade.

I recommend creating a new role clusteradmin:

kind: role
version: v3
metadata:
  name: clusteradmin
spec:
  # allow section declares a list of resource/verb combinations that are
  # allowed for the users of this role. by default nothing is allowed.
  allow:
    # logins array defines the OS logins a user is allowed to use.
    # A few special variables are supported here (see below)
    logins: ['root']

    # node labels that a user can connect to. The wildcard ('*') means "any node"
    node_labels:
      '*': '*'

    # see below.
    rules:
    - resources: ['*']
      verbs: ['*']

  # the deny section uses the identical format as the 'allow' section.
  # the deny rules always override allow rules.
  deny: {}

And updating users you would like to promote to clusteradmins with --set-role

[apiening]

Thank you for the explanation @klizhentas.
I will follow your suggestion with an additional clusteradmin role. This has the benefit that resources and verbs that might be added with future updates would be also allowed by this rule, because of the wildcards.