* Predicate expressions using the "name" identifier will now use
field "hostname" when `ls` querying for nodes, as expected by
the user
* Change predicate expression for access request that use
name identifier to using the actual json field names
This doesn't address the flakiness in TestRootScript, but it does:
- ensure that the background goroutine terminates
- ensure that test failures are only done in the main goroutine
- fix a race condition due to the shadowing of the 'err' variable
Updates #16908
This reverts commit 4f3aa9a3f2.
We're unable to build for 32-bit Linux due to
https://github.com/golang/go/issues/55152,
which looks like it will be fixed with Go 1.19.2 next week.
We'll re-evaluate with the next Go release and reintroduce this change
as soon as we can.
Do another large batch of dependency updates.
Most updates are around minor versions, so _theoretically_ safe. The following
v0.x updates draw attention:
* cloud.google.com/go/iam (likely safe, as Google is largely trunk-based)
* github.com/Microsoft/go-winio
Notable exceptions are k8s-related modules, which are harder to update for
various reasons.
* Update Go dependencies
* Fix lib/srv/app/aws/endpoints_test.go
Application sessions were previously only logged when launching an application
session via the UI, and not from the `tsh app login` command. This has been
corrected. The AppName and AppURI are now passed in as part of the gRPC
request to the auth server, which is then used to emit the audit event.
Label based tsh was sending UUID:0 as the node name to the
IsMFARequired check. The server was checking this name against each
nodes name and uuid. However the port included in the name prevented
any matches from being found. Which resulted in the ssh session being
rejected with an access denied message by the node because mfa was
required but never performed.
This removes the :0 from the node name to the IsMFARequired check and
adds a test case to TestSSHOnMultipleNodes that uses role based
per session mfa.
Update various "assorted" dependencies, that either are used throughout
(logging, testing), are mostly algorithmic or otherwise difficult to pinpoint
"ownership".
I've dropped a couple of deprecated/mostly meaningless dependencies. I suspect
`github.com/mitchellh/mapstructure` could be dropped to, but I didn't look
further now.
* Drop dependency on Clever/go-utils
* Drop dependency on github.com/pkg/errors
* Update various Go dependencies
* Use CompareAndSwap instead of CAS (uber/atomic)
* Add a comment after replaced dependencies
The 24-hour grace period was kept in Teleport 10 for backwards
compatibility, but is no longer necessary for Teleport 11 due
to the session tracker system.
As a result, it takes about an hour to complete an abandoned upload
instead of 24 hours.
* switch underlying protocol used for 'tsh scp' to SFTP
* address TODO
* appease linter
* add method to make it easier for other callers to transfer files
* add tests
* print transfer progress with progress bar by default
Also allow a SIGINT to gracefully stop the SFTP connection. This is
necessary because the progress bar will ignore signals and prevent the
process from exiting.
* address SFTP fork issues
* make tests less flakey
* fix specifying dir for dst not copying files to correct paths
* make tests less flakey (again)
* don't check file access times, often differs when run in CI
* few small fixes from review, simplify Create method now that HTTP FS isn't needed
* create dst files and dirs with src mode
* improved error messages when doing file operations
* expand home dirs in remote paths
* addressed more feedback
* add license to get_home_dir.go
* address minor feedback of tests, add home dir expansion test
* update sftp fork to point to latest commit on master branch
* addressed feedback
* don't cache home dir lookups, only one remote path can ever be used
* Introduce proto types for ProvisionTokenV3
* Add methods to ProvisionTokenV3 to support ProvisionToken iface
* Start building v3 support into the client
* add support for mashalling and unmarshalling ProvisionTokenV3
* Start unit testing ProvisionTokenV3
* Remove oneof to support yaml marshal/unmarshal
* Client should try V3 methods and fallback to v2
* More tests
* Fix join tests
* Fix integration tests
* Switch integration tests to use v3 spec
* Switch iam tests to use ProvisionTokenV3
* Change ec2 join tests to use V3 tokens
* Fix events tests for V3 token
* support ProvisionTokenV3 within API client events handler
* Explicitly specify JoinMethod
* Tidy up final usage of NewProvisionTokenV2FromSpec in tests
* Improve proto docs on ProvisionTokenV3
* Fix bot join tests
* Clarify error message for invalid join method
* Adjust resource version comment
* Fix comments and return error rather than bool in V2() method
* Catch incompatible conversions case
* Include V2 ProvisionToken in tests and add appropriate DELETE IN notes
* Fix linter warnings/unit test failures
* Use nolint rather than lint:ignore
* Add more DELETE IN notes
* Run goimports on join_ec2_test.go
* Address PR comments from tim.
* Add more deprecation/delete in notices
* Improve godoc comments on checkAndSetDEfaults for provider config
* Simplify implementation by dropping client-ahead compatability
* Add some support for client-ahead but with conversion to v3
* Update code comments to include responsible party
* Rename `Role` to `RoleARN` in EC2 configuration for clarity
* Fix tests for Role -> RoleARN rename
* Move MustCreateProvisionToken out of API and into test packages
* Properly go imports files
U2F devices, like the Yubikey4, fail in a slightly unexpected way when
assertions set UP=false. Handle this edge case and also make sure that failures
when checking for excluded credentials won't break the entire ceremony.
Similar to #15975, but in the registration flow this time.
Repro steps:
1. Register a Yubikey 4
2. Attempt to register a different security key
3. Registration fails with a "user presence required" error
* Reduce number of auth dials for tsh commands
One of the major areas of latency for `tsh ssh` is creating multiple
auth clients. Since the auth client is lazy and only actually performs
the dial on first use we can create an auth client once and simply
reuse it. This is done by adding an `auth.ClientI` to `ProxyClient`
which is created via `connectToProxy`. All attempts to connect to
the current auth server via the `ProxyClient` will be given the
cached `auth.ClientI`.
The new method of retrieving the current auth client also allowed
to remove a number of calls to `GetSites` which were used to obtain
the current cluster name. The local profile already contains the name
of the cluster and calls to `GetSites` were unnecessary. All instances
which relied on the site name now retrieve from information that the
`ProxyClient` already has.
In an effort to reduce ambiguity and confusion `CurrentClusterAccessPoint`
and `ClusterAccessPoint` were also removed. AccessPoint denotes that
you are connecting to a cache, but the `ProxyClient` is always going
to be hitting the auth server directly. The two have been replaced
with `CurrentCluster` and `ConnectToCluster`, which they were merely
wrappers for anyhow.
* Allow tsh to retrieve cluster details in one request
Prior to connecting to a node via `tsh ssh` we need two bits of
information about the cluster:
1) The session recording mode
2) Whether FIPS is enabled
In order to retrieve the information `tsh` first would send the
global ssh request `RecordingProxyReqType` to determine the
session recording mode. Later on `tsh` would Ping the auth
server to determine if the cluster was running in FIPS mode.
In an effort to reduce the number of round trips to retrieve
this data, a new global ssh request `ClusterDetailsReqType` is
introduced that returns both the session recording mode and
whether FIPS is enabled. This allows `tsh` to leverage the new
request to get all the information it needs, and is extensible
in case more information is needed` in one request which helps
reduce latency for `tsh ssh`.
By only providing the tunnel address from the `reversetunnel.Resolver`
callers would still need to lookup the proxy listener mode to determine
how to dial the address. This results in sending a request to
`/webapi/find` once by the resolver to get the tunnel address and then
a second request to `/webapi/find` by users of the `Resolver` to determine
the proxy listener mode. Propagating the listener mode along with the
tunnel address by the `Resolver` ensures only one `/webapi/find` call
is needed.
This is especially impactful because the `reversetunnel.TunnelAuthDialer`
which is used by the auth http client would do this everytime the
`http.Client` connection pool was empty. When the `http.Client` needed
to dial the auth server it was incurring the additional roundtrip to the
proxy.
trackSession was always using `s.serverCtx` instead of the passed
in context, which prevented having spans from being added to the
correct trace. Calls to NewSessionTracker now use the proper request
scoped context. The backgroun UpdateExpirationLoop still uses
`s.serverCtx`, but the span created for it is properly linked to
the request context.
* Leverage inventory control stream for instance version metrics
The version metrics relied on loading all resources in the cache on
each auth server to tally the counts. Unmarshalling items from the
cache can be quite expensive, especially when done every 15s for
all resources in a cluster. While auth servers are typically robust
machines the extra computation for calculating a single metric is
a bit costly and will grow with the cluster size.
Now that the inventory control stream provides a simple and efficient
manner to iterate over all connected instances we can leverage it
instead of the cache to calculate the version counts. This is a slight
breaking change however, as an auth server will now only be reporting
the versions of instances connected directly to itself, and not
versions for all instances within the cluster. This can easily be
worked around by aggregating the metric from all auth servers for
a cluster.
Closes#16429
Prior to this change, each individual service (proxy, app, SSH, db, etc)
would spin up its own uploader service. If you are running multiple
Teleport services in the same process, this means you get multiple
uploaders all looking at the same directory, which can result in
duplicate upload events in the audit log.
Additionally, desktop access has (mistakenly) failed to set up this
service, so desktop sessions would only be uploaded if you happened
to also run some other service in the same process that does spin up
the uploader.
Solve these issues by centralizing the uploader service so that it
runs once per process, and each Teleport service doesn't need to think
about whether or not the service should run.
Lisa Kim