Add a test for `services.ValidateLocalAuthSecrets` that includes all device
types and reintroduce a case mistakenly dropped by #10476.
I've elected to make `services.ValidateMFADevice` private and keep it around, as
this is the least intrusive change. All outdated TODOs are dropped.
#17853
WebAuthn recommends using a random user handle (aka user ID) in its protocol.
We are adding the user ID to LocalAuthSecrets (under Webauthn) and allowing it
to be updated and read, both through the user and independently.
The lib/auth/webauthn package is going to be responsible for assigning IDs to
users (and using them).
See https://www.w3.org/TR/webauthn-2/#sctn-user-handle-privacy.
WebAuthn Support RFD[1]
[1] https://github.com/gravitational/teleport/pull/7808
* Add Webauthn to LocalAuthSecrets
* Generate protos
* Add WebauthnLocalAuth persistence to Identity
* Remove JSON schema validation
Removing JSON schema validation from all resource unmarshalers.
--- what JSON schema gets us
Looking at the JSON schema spec and our usage, here are the supposed benefits:
- type validation - make sure incoming data uses the right types for the right fields
- required fields - make sure that mandatory fields are set
- defaulting - set defaults for fields
- documentation - schema definition for our API objects
Note that it does _not_ do:
- fail on unknown fields in data
- fail on a required field with an empty value
--- what replaces it
Based on the above, it may seem like JSON schema provides value.
But it's not the case, let's break it down one by one:
- type validation - unmarshaling JSON into a typed Go struct does this
- required fields - only checks that the field was provided, doesn't actually check that a value is set (e.g. `"name": ""` will pass the `required` check)
- so it's pretty useless for any real validation
- and we already have a separate place for proper validation - `CheckAndSetDefaults` methods
- defaulting - done in `CheckAndSetDefaults` methods
- `Version` is the only annoying field, had to add it in a bunch of objects
- documentation - protobuf definitions are the source of truth for our API schema
--- the benefits
- performance - schema validation does a few rounds of `json.Marshal/Unmarshal` in addition to actual validation; now we simply skip all that
- maintenance - no need to keep protobuf and JSON schema definitions in sync anymore
- creating new API objects - one error-prone step removed
- (future) fewer dependencies - we can _almost_ remove the Go libraries for schema validation (one transient dependency keeping them around)
* Remove services.SkipValidation
No more JSON schema validation so this option is a noop.
* Use cmp.Equal instead of manual Equals methods
Equals methods can get out-of-sync with the fields added in structs they
compare. Using `cmp.Equal` handles that, removes a ton of code and makes
it more explicit when specific fields are excluded from comparison.
* Use gogoproto equal plugin for comparing proto values
This will be faster than reflect-based go-cmp.
By specifying `device_attestation_cas` in `teleport.yaml`, admins can
restrict U2F device manufacturers. For example, specifying the yubico
attestation CA
(https://developers.yubico.com/U2F/yubico-u2f-ca-certs.txt), you can
restrict users to only yubikeys.
Example error when using the yubico CA and trying to register a Google
Titan key:
```
$ tsh mfa add --type u2f --name test && tsh mfa rm test
Tap any *registered* security key
Tap your *new* security key
ERROR: rpc error: code = InvalidArgument desc = U2F device attestation certificate is signed by "CN=Security Key,O=Google", but this cluster only accepts certificates from ["CN=Yubico U2F Root CA Serial 457200631"]; make sure you're using a U2F device from a trusted manufacturer
```
* mfa: add cluster-level require_session_mfa option
Users may choose to require MFA for all sessions in some clusters, or
only on select roles in others.
This PR adds the cluster-level option in the `auth_service` config.
To expose this field to non-auth services, opened up `GetAuthPreference`
access over the auth API, including all the cache plumbing.
* Address review feedback
Each user can now have multiple devices. This commit only changes the
backend structure to support it, the client and API haven't been updated
yet.
Also added a migration for existing MFA data on auth server startup.
* Support resource-based bootstrapping for backend.
Outside of static configuration, most of the persistent state of an
auth server exists as a collection of resources, stored in its
backend. The resource API also forms the basis of Teleport's more
advanced dynamic configuration options.
This commit extends the usefulness of the resource API by adding
the ability to bootstrap backend state with a set of previously
exported resources. This allows the resource API to serve as a
rudimentary backup/migration tool.
Notes: This features is a work in progress, and very easy to misuse;
while it will prevent you from overwriting the state of an existing
auth server, it won't stop you from bootstrapping into a wildly
misconfigured state. In general, resource-based bootstrapping is
not a complete solution for backup or migration.
* update e-ref
This commit expands the usage of the caching layer
for auth server API:
* Introduces in-memory cache that is used to serve all
Auth server API requests. This is done to achieve scalability
on 10K+ node clusters, where each node fetches certificate authorities,
roles, users and join tokens. It is not possible to scale
DynamoDB backend or other backends on 10K reads per seconds
on a single shard or partition. The solution is to introduce
an in-memory cache of the backend state that is always used
for reads.
* In-memory cache has been expanded to support all resources
required by the auth server.
* Experimental `tctl top` command has been introduced to display
common single node metrics.
Replace SQLite Memory Backend with BTree
SQLite in memory backend was suffering from
high tail latencies under load (up to 8 seconds
in 99.9%-ile on load configurations).
This commit replaces the SQLite memory caching
backend with in-memory BTree backend that
brought down tail latencies to 2 seconds (99.9%-ile)
and brought overall performance improvement.
Jakub Nyckowski