* 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.
* Compute warnings when mapping traits to roles
* Log warnings for case-insensitive traits to role matches.
Updates https://github.com/gravitational/teleport/issues/6016.
Co-authored-by: Andrew Lytvynov <andrew@goteleport.com>
In `GRPCServer` handlers, `g.Context` resolves to the context included
in `logrus.Entry` due to embedding.
This context is typically `nil`, so if anyone tries using it (such as
the `aws-sdk-go` when using a dynamodb audit backend), things break.
Use the `closeCtx` from the parent `auth.Server` instead.
* Avoid test flake by ensuring the gRPC server is shutdown gracefully before closing the audit log
* Fix lint warnings. Nove tunnel server's Close to earlier to close the proxy watcher and release grpc traffic
* Use graceful shutdown selectively until all tests have improved support for it
* Move session recorder clean up to session.Close
* Always use graceful shutdown for TLS.
Addresses issue #4924
If a default Web Proxy port is not specified by the user, either via
config or on the command line, `tsh` defaults to `3080`. Unfortunately
`3080` is often blocked by firewalls, leading to an unacceptably long
timeout for the user.
This change adds an RFC8305-like default-port selection algorithm,
that will try multiple ports on the supplied host concurrently and
select the most reponsive address to use for Web Proxy traffic. I
have included the standard HTTPS port (443) in the defaulut set,
and this can be easily expanded if other good candidates come along.
If the port selection fails for any reason, `tsh` reverts to the
legacy behaviour of picking `3080` automatically.
Forbids the use of the `--insecure` mode when FIPS mode is enabled in teleport
Disables the `--insecure` tsh command line option when built with FIPS support
See-Also: #5073
* client: set TLS certificate usage for k8s/app/db certs
--- TLS usage field
The certificate usage field prevents a certificate from being used for
other purposes. For example, a k8s-specific certificate will not be
accepted by a database service endpoint.
Server-side enforcement logic was already in place for a long time, but
we stopped setting the correct Usage in UserCertRequest during keystore
refactoring in 5.0 (with introduction of k8s certs).
--- TLS certificate overwrite
As part of this, client.ReissueUserCerts will no longer write
usage-restricted certificates into the top-level TLS certificate used
for Teleport API authentication.
For example, when generating a k8s-specific certificate, we used to
overwrite both:
- `~/.tsh/keys/$proxy/$user-x509.pem`
- `~/.tsh/keys/$proxy/$user-kube/$cluster/$kubeCluster-x509.pem`
This PR stops overwriting `~/.tsh/keys/$proxy/$user-x509.pem`.
This is not a breaking change.
--- Selected k8s cluster
Prior to this PR, `tsh status` printed the selected k8s cluster based on
the top-level TLS certificate. Since we no longer overwrite that
certificate, it will not contain a k8s cluster name.
Instead, we extract it from the kubeconfig, which is actually more
accurate since a user could switch to a different context out-of-band.
* Document UserCertRequest CertUsage enum values
