Master Ticket for 2.3

[kontsevoy]

This is the umbrella ticket for 2.3 milestone. The goal of this milestone is to clean up Teleport UX, particularly the CLI and configuration.

Namespaces

They are not launched yet. Namespaces should be removed from every user-facing component of Teleport, primarily from the docs. #1089

Role Format

resources clearly do not work for describing Teleport permission system. This comes from the fact that under the hood Teleport does not have real resources. Some things indeed are (like roles themselves or SAML connectors), but expressing permissions like "view other people's sessions" or "allowed to use web UI" or "deny interactive sessions" makes no sense using resources. To date, Teleport has been adding fake "resources" to get this done and we need this to stop.

Also, Teleport code is getting hard to read and understand when we reason about roles because we mix up real user roles with made-up roles for built-in Telerpot components (tokens, proxies, auth).

1. Proposal: separate UserRole from ServiceRole inside of Teleport code. [REFACTORING] Different data structures for services and rules #1093
2. Proposal: create high-level "permissions" (or "rules", how they are called in Kubernetes) that can be assigned to user roles. Expanded Role format  #1092
3. Treat "resources" as a logical object (for example "audit_log") vs a specific thing defined in YAML, like a pod in Kubernetes. This is not actionable proposal, but also falls under Expanded Role format  #1092.

Combination of proposals 2 and 3 means that this change will be very light-weight and will not affect resource-based security of service roles (machines joining clusters, etc)

Role Templates

They need to go. It is a misfeature that defeats the purpose of having roles, instead of being a template, they are actually "role generators" that generate a role-per-login. This makes it hard to manage roles and reason about security.

Proposal: to allow variables inside role definition, something like %user.login%. This is also covered in "Using Variables" section of #1092

Dynamic Configuration

Kubernetes-inspired "resources" is a good idea, but it does not work in practice for several reasons:

We cannot represent dynamic configuration as a resource. The cluster configuration is a singleton. You cannot have more than one. You cannot have zero configurations. Using resource-like CLI to flip single values inside of a singleton config is a hack.

Details in #1098

Resources

Well... if "auth preference" is not a resource. What is a resource then?

A proper resource should have a true CRUD semantics: i.e. get, list, create, delete, update. We also have strange resources like SAMLResponse. What is that? Why do they exist? This is just a temporary data structure inside Teleport. Things like "reverse tunnels" or "certificate authorities" are the same: they are not user-visible resources, they are internal data structures.

Details in #1137

CLI syntax

Currently the CLI for working with resources is not polished. The proper usable resources CLI should allow you to dump 100% of Teleport resources into stdout, save it into YAML files, delete them all, restart teleport and re-create everything from a dump.

Also, if we are going to stop treating dynamic configuration as a resource, we need a new configuration CLI.

Open source Teleport does not support UserRoles. The CLI experience needs to reflect that. Showing auto-generated roles like ekontsevoy:ekontevoy is confusing.

Local Logins

Teleport should always allow local user logins. This is needed for situations when your SAML/OIDC authentication is broken (the provider is down, or you have uploaded a broken role) and you need to get into the box (or web UI) somehow.

• Proposal: web UI should always have local login auth in addition to "Login with SAML" button(s)
• Proposal: CLI tsh login should support --auth=local flag (we used to have it, probably still do).

Issue: #1090

[kontsevoy]

woo!