* Add support for automatic user provisioning
* Add UID parker to reexec
* Add a `teleport park` subcommand that does nothing
Co-authored-by: Edoardo Spadolini <edoardo.spadolini@goteleport.com>
After the merge of https://github.com/gravitational/teleport/pull/12674 we no longer use the following configuration:
```yaml
teleport:
ca_signature_algo: "rsa-sha2-512"
```
As we now rely upon the `x/crypto` package to choose the signing algorithm (it defaults to `rsa-sha2-512`)
**Demo**
If we set `ca_signature_algo` (the value is irrelevant) and start `teleport` we get:
```shell
root@marco:/workspace# teleport start --debug
2022-06-02T09:33:58Z WARN ca_signing_algo config option is deprecated and will be ignored, we'll always default to rsa-sha2-512. config/configuration.go:348
2022-06-02T09:33:58Z INFO Generating new host UUID: b001159a-10e0-49a7-b4dc-61c73fbe9e42. service/service.go:726
...
```
Fixes#12905
* Add client side circuit breaker to auth clients
In order to apply back pressure we can utilize a circuit breaker that
monitors error responses from auth server. When tripped it will prevent
all outbound requests to auth for a period of time. This can also help
prevent a potential thundering heard when auth is in an unhealthy state.
By default the circuit breaker will only be tripped if 90% of the
requests made in the monitoring interval fail.
We are developing a K8S Operator for Teleport
We want to keep track of the resources created by the operator.
We'll set the `metadata.labels[OriginLabel]` to `kubernetes`
To do so, we must create this new constant and add it to the list of
possible Origins
This adds proxy peering support. A configurable setting that allows for agents
to connect to a subset of proxies and be reachable through any proxy in the
cluster. This is achieved by creating grpc connections between each proxy
server. Client connections can then be passed between proxies to the desired
agent.
* Span forwarding
Modifies the auth grpc server to implement the OTLP Collector
RegisterTraceServiceServer API (https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/collector/trace/v1/trace_service.proto).
This allows the auth server to receive spans from other services
like `tsh`, `tctl`, and `tbot`. Any spans received by the auth
server will be forwarded to the exporter configured via the
`tracing_service` if it is enabled. All received spans will be
dropped in the event that the`tracing_service` disabled. By
forwarding spans to the auth server, `tsh` doesn't need to
be provided with any of the telemetry backend information
to have its spans exported.
Adds a new `--trace` flag to `tsh` to enable collecting and
forwarding spans to the auth server. When set, the tracing
provider is initialized with a sampling rate of 1.0 to force
all spans to be recorded. Teleport respects the sampling rate
from remote spans, which means that when `--trace` is set, all
spans from `tsh` and any downstream Teleport services will be
recorded and exported regardless of the sampling rate that each
Teleport service is configured with.
* convert GetDomainNAme endpoint to gRPC
* migrate GetClusterCACert from http to grpc
* fix tests failing due to switch to gRPC transport
* Correct mispelt json tag
* remove `GetLocalClusterName` and `UpsertLocalClusterName` which are unused
* remove unused prefix constant from presence
U2F facets don't serve a purpose since Webauthn became the de-facto MFA
mechanism. This should make it easier for users to write v10-style
authentication configs.
The remaining U2F fields are still relevant for when we derive Webauthn settings
from U2F, so those are kept (and validated).
Note that we still keep the fileconf field, since we don't want configs to
needlessly break during version upgrades.
#10375
* Remove references to U2F.Facets
* Remove Facets from U2F proto
* Reinstate proto Facets field
U2F gets marshaled as JSON to storage, so we better keep the field to
avoid issue with resource configs.
* Add deprecation notice on comment
* Update generated protos
When the client connects to teleport with invalid credentials (eg
expired ones) it will retry multiple times until the context deadline is
reached.
When it happens, we receive the generic error: context deadline
exceeded.
However, we can ask for the latest connection error, one which will give
us more information on why it happened.
To ask for this extra error we need to add the following
grpc.DialOption: grpc.WithReturnConnectionError()
After doing this, we will get the errors that happenned when trying to
connect to the grpc Server.
This should help us debug possible connection problems.
We had to refactor a little bit the way we handle the parallel
connection attempts to receive all the connection errors from the
multiple flows.
* Add tracing instrumentation for ssh clients/servers
Add tracing context to the existing ProxyHelloSignature to provide
span information across ssh connections. To add span context per
ssh session on top of new connections, the same tracing context is
passed in the first global request of the session.
In order to ensure that tracing context is pulled from and inserted
into the proper context.Context, some interfaces and methods were
changed to take one as the first argument.
* New method: GetCurrentUser().
GetCurrentUser returns current user as seen by the server.
Useful especially in the context of remote clusters which perform role and trait mapping.
* Fix "tsh db ls" for remote clusters.
Attempt to resolve remote roles and traits. Fail gracefully if this isn't possible.
* add client ip and user agent to `user.login` audit log
* reuse existing ConnectionMetadata message
* additional audit data for SSH logins made via proxy
* small unit test for clientMetaFromReq
* add franktentest for login checking audit event
* fix audit logging timestamps in web/auth tests
* Respect timeout in `(directDial).DialTimeout`
* Add a Timeout to the api/client/webclient calls
* Respect timeout in (proxyDial).DialTimeout
* Applied suggestion
Co-authored-by: Alan Parra <alan.parra@goteleport.com>
Co-authored-by: Alan Parra <alan.parra@goteleport.com>
* Allow register passwordless on invite/reset
* Specify the type of device usage when registering new device
* Minor refactoring to reduce number of parameters to funcs
* Check if device register requested pwdless, response is pwdless capable
Why
---
Current CA rotation require you to rotate the key 3 times
* `init` - to add new CA to the DB
* `update_clients` - to generate new client certificate and add it to DB
* `standby` to remove the old CA from DB.
If any of the steps is skipped the integration will stop working as either Teleport or DB are not able to authenticate the connection.
Solution
---
Signing the client certificate with the new CA will allow to reduce the number of certificate updates and potencial DB restarts/reloads that should make the procedure simpler and less error prone. From now on the certificate will only need to be updated on `init` phase and after `standby` to remove the old CA.
Co-authored-by: Jim Bishopp <jamesbishopp@gmail.com>
* Add new `identityfile` config template to `tbot`
This adds a new `identityfile` config template to tbot which
generates an identity file from any of the formats supported by
`tctl auth sign`.
It can be used by specifying one or more formats in the configuration
like so:
```yaml
destinations:
- directory: /foo
kinds: [ssh, tls]
configs:
- identityfile:
formats: [file]
```
It requires both SSH and TLS certificates to work properly. App,
Kubernetes, and Database certs are unlikely to work as they have
additional cert requirements that will be added in separate PRs.
Multiple formats can be specified, and each will be written to its
own subdirectory within the destination using the name of the format.
The particular files written inside this directory depend on the
particular format selected, but n the above example, this means a
file named `/foo/file/identity` is written.
The files all have an `identity` prefix at the moment. This could be
made configurable if desired.
The `file` format can be used in conjunction with `tsh -i` and
`tctl -i` to use those tools with a tbot-generated identity.
Fixes#10812
* Make identityfile formats first-class config templates
This promotes most of the important identityfile formats to proper
config templates. User-facing `kinds` are removed to reduce confusion
and several config templates are now required.
* The `ssh_client` template is now required and will be added
automatically in all cases if not specified.
* A new required `tls_cas` template is added to always export
the current Teleport server CAs in a usable format.
* A new required `identity` template is added to always export an
identity file usable with tsh/tctl.
* New optional `cockroach`, `mongo`, and `tls` templates can export
specifically-formatted TLS certs for various databases and apps.
Additionally some other changes were caught during testing:
* `botfs` now allows users to specify if files should be opened for
reading or for writing; previously, written files were never
truncated when opened for writing leading to garbage at the end of
files if the length changed. Truncation isn't sane for reading so
the two use-cases are now split.
* Update lib/client/identityfile/identity.go
Co-authored-by: Jakub Nyckowski <jakub.nyckowski@goteleport.com>
* Address first batch of review comments
Tweaked the `botfs.openStandard` and `botfs.openSecure` functions to
accept a plain file mode, and removed a ton of boilerplate in
`configtemplate.go`.
* Fix problematic nil interface check in configtemplate
* Clarify comment about `client.Key` DB certs
* Address review feedback
- Use `DatabaseCA` for database specific templates; make the `tls`
template's CA configurable; write the database CA alongside the
others.
- Simplify nil interface check
* Fix outdated var names
Co-authored-by: Jakub Nyckowski <jakub.nyckowski@goteleport.com>
* Changes for tctl sso test, tctl sso configure commands.
* Log SSO diagnostic information for SSO test flows.
Co-authored-by: Roman Tkachenko <roman@goteleport.com>
Leverage otelhttp to generate spans for http clients and http handlers.
Additionally add spans for grpc clients and servers by using the
otelgrpc interceptors. This is step one in implementation of RFD 65.
Until further work is done, the spans generated will be a no-op
until the tracing provider is initialized.
Joel