* 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.
* Prevent race from causing remote clients from being closed
`web.SessionContext` was susceptible to races retrieving `auth.ClientI`
for remote sites. The mutex on the remote client cache was not held for
the duration of the `GetUserClient` which meant two simultaneous requests
could find no client existed in the cache, create one and then add it to
the cache. When the second client is added to the cache it would close the
first client created, which results in the `use of closed network connection`
error displaying on the web UI as described in #17173.
To remedy this the portion of `GetUserClient` that retrieves the remote client
is now protected by a `singleflight.Group`. This ensures that races on creating
a client no longer happen.
`web.SessionContext` was slightly refactored to make it easier to test, to
remove some unnecessary operations, and to provide `context.Context` to `GetUserClient`.
Additionally, all `web.SessionContext` variables which were named `ctx` in `lib/web`
have been renamed to avoid confusion as that often refers to a `context.Context`.
Fixes#17173
* 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 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 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
Fixes total count errors for the web UI:
- Adds de-duplicating matches for `FakePaginate` func.
- This change does makes `FakePaginate` less efficient b/c
it will always run filter for every resource per fetch versus just
running it on the initial fetch to get the total count.
- Removes inaccurate de-dupping in the web api layer since we
do it from the back now
- Adds another criteria when de-duplicating `applications` by checking
for its `public_addr` as well as its name.
* Created a general listResourcesGetResponse as a consistent return value
* Wrapped response in ^ object for resources that were not wrapped to
accommodate future changes (dbs, desktops, kubes)
* Add support for windows desktop services proxying different desktops
* Add filter to GetWindowsDesktops, remove GetWindowsDesktop and GetWindowsDesktopByName
* Cache cleanup
* Fix cache deletes for Windows desktops
For deletes, the cache only gets the backend key, not the entire
resource. Do what database access does, which is to extract the
host ID from the path, and stuff it in the description field of
the resource header.
* Godoc cleanup
* Fix lint
* Address review comments
* Send error message if no desktop found
* Revert to x/net/websocket
This got converted to gorilla/websocket as part of moderated sessions.
We'll do a more intentional conversion post-release.
* fix lint
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
* 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