* Removes desktop logins from the ACL and adds them to each Desktop resource
as returned to the frontend. This behavior parallels what's currently being
done with other similar resources such as Nodes, and fixes a bug where
users were able to see all the logins permitted by their roles on every
desktop "connect" dropdown, even if the role permitting that login didn't
apply to a given desktop.
* Extracts common logic out of GetWindowsDesktopLogins (now GetAllowedWindowsDesktopLogins), uses it to create a GetAllowedServerLogins as well, tests both of them together, removing EnumerateServerLogins
* reduce unnecessary looping by using maps
* fixes flakiness by sorting lists
* uses require.ElementsMatch rather than manually sorting lists
* consolidates duplicated logic
* Consolidates separate server and desktop logic into a single GetAllowedLoginsForResource
* fixes tests
* fixes import order and test
* DatabaseService resource: client and server CRUD
In the context of Teleport Discover, we must be able to known if there's
any DatabaseService available to proxy a given Database resource.
If there's none available, we will offer a script for the user to run
and install a DatabaseService which proxies the desired Database
resource.
By DatabaseService, we mean the process that Teleport binary manages
when the `teleport.yaml` config has the following section:
```yaml
db_service:
enabled: "yes"
```
To accomplish this we are creating a new resource: DatabaseService.
The UI will fetch all DatabaseServices and check if there's any
ResourceMatcher that matches the DatabaseLabels.
A previous PR created the DatabaseService resource.
This PR creates all the necessary CRUD operations:
- Add Service to manage DatabaseServices resources in the backend.
- Add GetAll, Upsert, Delete and DeleteAll operations to Client.
- Add DatabaseService support to ListResources.
- Add WebAPI endpoint to list DatabaseServices using ListResources.
The next PR will add the heartbeat mechanism to the DatabaseService
process.
* Add db access rule required for db discovery
in editors role
For the webapi layer:
* Return db access with user context
* Add AWS RDS fields for creating db request
* Return hostname of each queried db server
* hide labels from UI
* add test cases for hidding teleport.internal/ labels
* move labels logic to separate file
* move constant to right api/types/constants.go
* add godoc to makeLabels and rework label constants
Co-authored-by: Jim Bishopp <jim@goteleport.com>
* WebAPI: Get database endpoint
This commit creates a new endpoint to return a single databse by its
name.
```
GET /webapi/sites/:site/databases/:database
{
"name": "<database_name>",
"desc": "<description>",
"protocol": "<protocol>",
"type": "<type>",
"labels": [
{"name": "<name>", "value": "<value>"},
...
],
"database_users": ["<db_user1>", ...],
"database_names": ["<db_name1>", ...],
}
```
The `database_users` and `database_names` will list the available
Database User and Names for the current user, based on its roles.
This commit adds two new endpoints:
Create a database with
```
POST .../databases
{
"name": "<databasename>",
"protocol": "<protocol>",
"uri": "<uri>",
"labels": [{"name":"<name>", "value": "<value>"}...]
}
```
Update a database's `ca_cert` (the only updatable field for now)
```
PUT .../databases/:database
{
"ca_cert": "------BEGIN CERTIFICATE-----\n <certificate> --END..."
}
```
This PR returns a list of allowed principals that a user is authorized to impersonate for each Kubernetes cluster.
When a Teleport user has multiple Kubernetes users defined for the same Cluster we must allow him to choose one otherwise the request will return an error. Similar to `kubectl get pods --as {user} --as-group {kubeGroup}`.
If the user selects invalid users or groups, it will return invalid Kubernetes principals.
Closes#17382
This PR implements the SSH Tester for ConnectionDiagnostic feature.
This feature is also known as Test Connection, part of Teleport
Discover.
The goal here is to provide immediante feedback about a newly added
resource. Can the user connect to it?
We are targetting SSH Nodes as a first ResourceKind.
To test the access to an SSH Node we require the ResourceName and a
login username (ssh principal).
Then a series of checks will occur in two places:
- SSH client in the Web server
- SSH server in the SSH agent
The ssh client creates a new Connection Diagnostic with some initial
state.
Then it tries to build up the necessary SSH config
This already gives us a couple of things to check for:
- does the node exist and does the current user (inherited from
websession) can access it?
- is the node accepting TCP connections (in the specific port)?
- is the node accepting SSH protocol on top of the TCP connection?
Then, the ConnectionDiagnosticID is inject into the certificate and the
SSH Server receives it and will also Append traces into it:
- is the requested principal allowed for the current user?
- does the requested principal exist in the target node?
This is not an exhaustive list of checks.
For a complete list of which checks are verified please see the
TestDiagnoseSSHConnection test.
After all those checks, it returns if the Connection was successful and
what all of the traces generated along the way.
Demo:



This PR adds the concept of ConnectionTester
ConnectionTester will generate ConnectionDiagnostics by connecting to
the actual resource using a user and some Resource Specific parameters
(principal for SSH access, Database User and Name for Database access,
and so on) and storing the result of multiple checkpoints.
Each resource will have a ConnectionTester (we'll start by SSH access
and then Databases).
It also improves Connection Diagnostics by adding
- update operation (similar to the create one)
- a list of traces, which contain the result of checkpoints in multiple
steps of the connection flow
As an example, for SSH, we'll have at least the following checks:
- Node is reachable
- User has the right permissions
- Node has the expected Principal
The trigger to test a connection will be an endpoint, because our
primary goal is to let the user test the access right after adding the
resource.
This PR does not implement the actual SSHConnectionTester but creates
most of the boilerplate to do so.
The next PR will focus in adding the actual traces.
In Teleport Discover, we want to improve the UX of adding a resource.
We'll suggest users to test accessing a resource, and give them immediate feedback using the UI.
Note: we'll add this feature to Server Access, later one we'll add other resources.
After adding a server resource, the user will be presented with a command to test the connection:
`tsh ssh --test-id=123 user@host`
Running that command will provide the user feedback right in the UI of whether or not it worked.
If not, a short message will be displayed describing why it didn't work and how the user can solve the problem.
---
To achieve this we'll need a couple of changes:
1. new resource that stores the result of trying to connect to a given resource, so that the UI can ask for it
2. change `tsh ssh` to receive the `--test-id` flag and write the result to a record of this new resource
This PR addresses 1 - new resource.
A new resource is created:
```
Connection Diagnostics
- success (bool)
- message (string)
```
Two new rpc methods:
- create connection diagnostics
- read connection diagnostics
One new HTTP Endpoint:
- read connection diagnostics
Related to
https://github.com/gravitational/teleport/issues/13957
* updates endpoints
* Exposes an endpoint for fetching a single desktop by name
* Apply suggestions from code review
Co-authored-by: Zac Bergquist <zmb3@users.noreply.github.com>
* changes inaccurate desktopUUID to desktopName
Co-authored-by: Zac Bergquist <zmb3@users.noreply.github.com>
* Connect proxy <-> windows_desktop_service <-> RDP server
Link together the proxy (websocket), service (mTPS) and RDP client. Pass
target desktop UUID via SNI on the TLS connection from the proxy.
* Use client CAs to validate incoming desktop_service connections
* Send binary frames on desktop websocket