Define access requirements for Teleport Service

Now that the Teleport service is running and being used for real work, it's time to revisit some of the outstanding questions regarding who has access to what.

Teleport provides Roles, which are a container for any type of access. Roles are not opinionated. They just configure the ability to do something. It is up to us to decide what groupings of permissions are appropriate for our situation. After running things for a while, it looks like it's going to make the most sense to split the concept of role into Access Roles, Requestor Roles and Approver Roles.

Access Roles

These roles provide actual access to services. Groups of people can have them by default or can request them.

• database-ro
• database
• rails-ro
• rails
• shell

Requestor Roles

These roles allow a group of people to request an access role.

• request-rails-ro
• request-rails
• request-database-ro
• request-database
• request-shell

Approvers

These roles allow a group of people to approve a specific type of role request.

• approve-rails
• approve-database

Configuration

Roles are assigned to Okta groups. By splitting up the roles this way, we can be much more granular about which Okta groups can do what, and which approvals are required.

• GitLab - Backend Engineers roles: [request-rails-ro]
• GitLab - Fullstack Engineers roles: [request-rails-ro,request-database-ro]
• GitLab - Backend Engineering Managers roles: [request-rails-ro]
• GitLab - Support Engineers - Console Access roles: [request-rails-ro]
• eng-quality-dev-members roles: [request-rails-ro]
• GitLab - SRE Managers roles: [approve-rails,approve-database]
• GitLab - SRE roles: [rails,database,shell,approve-rails,approve-database]

Information still needed

• What is the name of the Okta group for database engineers?