Delete user k8s, etc. certificates on re-issue
Prior to this change, user certificates for services like kubernetes were
preserved across a certificate re-issue. This led to issues where elevated
privileges granted by an access request were not applied to the service
certificates as they were not updated during the reissue process.
This patch changes the certificate re-issue process such that:
* certificates for services (like Kuberenetes) are not preserved
over a certificate re-issue. It is expected that they will be recreated
on the first access to the service in question, and
* the local keystore files for these certificates services are explicitly
deleted so that the now-invalid cached certificates are not returned
on keystore queries.
See-Also: #5047
* Init web handler with auth server feature flags on proxy init
* Retrieve auth server features by calling Ping when connecting
to auth svc which contains the server feature flags in the response
Updated TLS handshake timeout. During some operations, Teleport can
flood the network with traffic which causes the TLS handshake to occur
slower than 1 second.
One example is during SSO login. The initial connection is an
unauthenticated connection, and upon successful SSO login a "types.User"
is created and replicated to all nodes. For large clusters this can mean
10k+ "types.User" objects getting replicated at the same time the user
attempts to re-establishing another connection to Auth this time with
valid identity credentials. This connection sometimes can take longer
than the original 1 second timeout.
This commit removes copying of stdout and stderr from non-interactive
ssh commands to stdout and stderr of the teleport server process. This
was introduced in e65eac59b0 and appears to have been put in for
debugging.
* mfa: only reject last device deletion of correct type
For example, when OTP is required, only reject the deletion of the last
*OTP* device. Don't reject deletion of a U2F device even when there's
only 1 OTP device left.
* Update grpcserver.go
* kube: handle large number of trusted clusters in mTLS handshake
Same as https://github.com/gravitational/teleport/issues/3870 but for
k8s endpoints. There is a hard limit on how many CAs we can put into a
client CertPool, usually several hundred (depending on Subject length).
The solution here is to fall back to only using the current cluster's CA
for validation if the limit is reached. This is almost always the case
in root clusters. There, the client certificate will be signed by the
root cluster and validation will pass.
In the unlikely case that you have a leaf cluster which in turn has
hundreds of trusted leaf clusters itself, the validation will fail. The
client cert will still be signed by the root cluster (not the leaf).
However, that's better than a panic. And I'm not aware of any real
setups like that.
Also in this PR, add the wildcard `*.teleport.cluster.local` SAN to
proxy and k8s TLS certificates, which was missing before. This SAN is
used for clients to encode the cluster name and pass it in SNI. The
client (kubectl) is not updated to set this SNI yet, it would break
existing clusters without the SAN change.
* add SNI tests for k8s
Test that mTLS works with large numbers of CAs.
Implement context-based cancellation in `/lib/utils/prompt`, for MFA
prompts.
This fixes the following scenario:
```sh
User has both OTP and U2F devices registered.
$ tsh mfa ls
Name Type Added at Last used
----- ---- ----------------------------- -----------------------------
otp TOTP Wed, 21 Apr 2021 19:41:44 UTC Wed, 21 Apr 2021 19:44:32 UTC
usb-a U2F Wed, 21 Apr 2021 19:44:34 UTC Wed, 21 Apr 2021 19:44:34 UTC
Add a new OTP device, using existing U2F device:
$ tsh mfa add
Choose device type [TOTP, U2F]: totp
Enter device name: otp2
Tap any *registered* security key or enter a code from a *registered* OTP device: <tap> # <- First OTP prompt here
Open your TOTP app and create a new manual entry with these fields:
Name: awly@localhost:3080
Issuer: Teleport
Algorithm: SHA1
Number of digits: 6
Period: 30s
Secret: 3UD42X2NN7EEZ6LUPG6NFMNOLDY6AJTS
Once created, enter an OTP code generated by the app: 607738 # <- Second OTP prompt here
MFA device "otp2" added.
```
Before this PR, the first OTP prompt (for `*registered* device`) would
hang in the background. The OTP code from the newly-registered device is
prompted later, but any text written ends up going to the first prompt.
After this PR, the first prompt is canceled and the code from a new
device goes to the second prompt as intended.
Note: this is implemented using pure Go code (background goroutine
consuming `os.Stdin`) rather than syscalls (e.g. `poll` or `select`)
for portability.
* mfa: prevent the user from deleting the last MFA device
When the cluster requires MFA for all users (when `second_factor` is
`on`, `u2f` or `totp`, and not `off` or `optional`), users could lock
themselves out by deleting the last device. Prevent that.
Fixes https://github.com/gravitational/teleport/issues/5803
* Make last MFA device deletion check more strict
Separate by the type of the device and which type the cluster enforces.
Several improvements:
- show a QR code in the system image viewer
- print an OTP URL in addition to individual fields (some apps accept
that as input)
- use cluster name as `Issuer` instead of "Teleport"
For some resource kinds, `tctl get` used to always return the list of
all resources of that kind, irrespective of whether a specific resource
name was given in the argument to `tctl get`.
For instance, `tctl get node/node-id` would have always listed all the
nodes (just like mere `tctl get node`).
Here, all `tctl get` handlers are adjusted to filter by name when a name
is provided as part of the input ref.
Currently, an app's target FQDN can be obtained only using the endpoint
for creating new app sessions. The OAuth-style back-and-forth redirects
between the app launcher and the app itself are therefore forced to
generate an unnecessary additional app session just to resolve the FQDN.
The new endpoint introduced here allows to resolve such FQDNs by
invoking a dedicated endpoint.
