* Add GetType() to Plugin
* Add Plugins feature flag to web
* Run prettier
* Update e_imports.go with slack plugin subpackage
Respective enterprise changes imports a new subpackage,
which pulls new dependencies.
* 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
This PR includes a new Role resource version that is compatible with V5 spec.
The new resource introduces the `kubernetes_resources` definition that allows operators to limit the Kubernetes resources that each member can access. The `kubernetes_resources` entries must follow the following format: `{"kind":"<kind>", "namespace":"<namespace>","name":"<pod>"}`. Currently, it only supports objects of `kind` `pod`. Valid examples `<namespace>/<name>:
- `*/*`: matches all pods in all namespaces.
- `default/*`: matches all pods in the `default` namespace.
- `*/nginx-*`: matches every pod prefixed with `nginx-` in every namespace.
For older resource versions - V5, V4, V3 - `kubernetes_resources` is automatically populated with `{"kind":"pod","namespace":"*","name":"*"}` to keep compatibility. For the newest version, it's mandatory to define its value otherwise access to pods will be denied.
Part of #18434
* 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>
We were inconsistent throughout the codebase and would sometimes
use the slices package and other times use our own equivalents
in api/.
This removes our versions in favor of the golang.org/x package that
does the same, which has the added benefit of reducing the surface
area of the public API module.
Note: despite existing uses of the slices package, for some reason
it didn't show up in go.mod or go.sum. Fixed that too.
* 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..."
}
```
- When user registers or resets, when running into
policy errors, we don't send back an error, but instead
a 200 (to indicate user has successfully registered/resetted)
and a flag to determine if policy was enabled
- Send back policy configurations for cluster config,
this will allow the web UI login page to just display
redirection messages without login attempts
- For role configured policy, login attempts will be
required and a specific error will be returned so that
the UI can then better redirect the user
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:
* Add connection diagnostic access to UI user context
* Implement resource checker in the web api layer
* Remove setting NeedTotalCount flag for web api list resources
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.
## What
First part of the Kubernetes [Discovery RFD](https://github.com/gravitational/teleport/pull/13376/) to introduce a Kubernetes server per cluster.
This PR introduces a separate Kubernetes server that uses the already introduced `KubernetesClusterV3`.
## Compatibility
In previous versions, Kubernetes Clusters were part of regular `ServerV2` resource and this refactoring deprecates the `ServerV2` usage but keeps them for compatibility with previous version.
Everything is backward compatible, so v10 kubernetes agents and trusted clusters can connect fine.
## Next steps
Once this is merged, a new PR will introduce dynamic registration for Kubernetes Clusters discovered through EKS Discovery.
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
* configure golangci-lint misspell to check for anglicized spellings
* Americanize spellings
* fix aws constant value with british spelling 🇬🇧
* update api types with americanized spellings
* use american spellings .cloudbuild/scripts
* WebAPI: read user
We currently need to fetch the whole list of users to get User's
information.
Adding more fields increases the probabilty of having performance
issues.
This PR adds a new endpoint which returns a single user.
This endpoint returns the information we already return when listing
users but also returns the user's traits
This is a follow up of
https://github.com/gravitational/teleport/pull/14076
The following traits are returned:
- Logins
- DB Users
- DB Names
- Kube Users
- Kube Groups
- Windows Logins
- AWS Role ARNs
The web api cannot leverage the NodeWatcher because it needs to
have each request for nodes go through RBAC checks per user. Rolling
back to creating an auth client per user and retrieving nodes
directly from the auth.ClientI.
* Prevent proxy from loading entire node set into memory more than once
When establishing a new session to a node, the proxy would load the
entire node set into memory in an attempt to find the matching host. For
smaller clusters this may not be that problematic. But on larger clusters,
loading >40k nodes into memory from the cache can be quite expensive.
This problem is compounded by the fact that it happened**per** session,
which could potentially cause the proxy to consume all available memory
and be OOM killed.
A new `NodeWatcher` is introduced which will maintain an in memory list
of all nodes per process. The watcher leverages the existing resource
watcher system and stores all nodes as types.Server, to eliminate the
cost incurred by unmarshalling the nodes from the cache. The `NodeWatcher`
provides a way to retrieve a filtered list of nodes in order to reduce the number
of copies made to only the matches.
* Move WebConfig from lib/web/ui to api/client/webclient
Web config was shared with the Web UI through the dynamically generated
/web/config.js file available on the cluster. With the addition of
Teleport Terminal (RFD 63), the Electron app needs to get a hold of this
config as well.
However, unlike the Web UI which directly loads the file and injects
the config this way, any communication between the cluster and Teleport
Terminal is done through the tsh daemon (RFD 63). The tsh daemon needs
to essentially pipe this config from /web/config.js to the gRPC response
it gives to Teleport Terminal.
To achieve this, a GetWebConfig function was added to TeleportClient.
Unfortunately, this breaks the build on Windows as lib/web (where WebConfig
resides) includes code which is not meant to be compiled or run on Windows.
Since we need to share the web config with another frontend application,
it only makes sense to move it to the webclient package. We already have
types shared between the server and the client there, for example the
PingResponse struct.
* Adds a DesktopSessionRecording flag to the ACL to tell the frontend whether or not a user's desktop sessions are being recorded.
* Accounts for the fact that desktop recording may be disabled globally
* fixes linting error
The use of a re-badged buildbox image (rebadging quay.io/gravitational/teleport-buildbox to us-docker.pkg.dev/ci-account/teleport/buildbox-root) is holdover from when CI builds required separate "root user" and "non-root user" images to execute tests under different contexts.
This requirement has since been lifted by using a Go-based build script in CI, and the having to manually invoke a process to re-badge the buildboxes is, tedious, confusing and causing stoppages.
This patch restores the use of buildboxes from quay.io in CI.
Introduce the GuessIfAccessIsPossible method, so callers may verify if a user
has access to a category of resources, instead of access to a specific resource.
Fixes a bug where the "Session Recordings" menu doesn't show for users with
where-based roles.
Justinas Stankevičius
