Internal server error due to long AWS AssumeRole session name

[joaoubaldo]

Expected behavior:
I expect calls to AWS API via tsh to succeed (eg. tsh aws s3 ls) even when logged in to a leaf cluster via its root cluster.

Current behavior:
After logging in to a leaf cluster via its root cluster, I get an error when making an AWS API call via tsh, such as:

$ tsh aws s3 ls

An error occurred (500) when calling the ListBuckets operation (reached max retries: 2): Internal Server Error
ERROR: exit status 254

Running the same command with debug enabled:

$ tsh -d aws s3 ls
...
2024-07-30T16:59:32+01:00 WARN [LOCALPROX] "ERROR REPORT: Original Error: *awserr.requestError ValidationError: 1 validation error detected: Value 'remote-some.randomname@jumo.world-teleport.test-vocal-cougar.eu-dev.awsmmcn.private' at 'roleSessionName' failed to satisfy constraint: Member must have length less than or equal to 64
	status code: 400, request id: 2542a4b3-49c3-4c85-970b-f4ae10de6583 Stack Trace:
	github.com/gravitational/teleport/lib/utils/aws/signing.go:183 github.com/gravitational/teleport/lib/utils/aws.(*SigningService).SignRequest
	github.com/gravitational/teleport/lib/srv/app/aws/handler.go:168 github.com/gravitational/teleport/lib/srv/app/aws.(*signerHandler).serveCommonRequest
	github.com/gravitational/teleport/lib/srv/app/aws/handler.go:152 github.com/gravitational/teleport/lib/srv/app/aws.(*signerHandler).serveHTTP
	github.com/gravitational/teleport/lib/srv/app/aws/handler.go:129 github.com/gravitational/teleport/lib/srv/app/aws.(*signerHandler).ServeHTTP
	github.com/gravitational/teleport/lib/srv/app/connections_handler.go:369 github.com/gravitational/teleport/lib/srv/app.(*ConnectionsHandler).serveSession
	github.com/gravitational/teleport/lib/srv/app/connections_handler.go:446 github.com/gravitational/teleport/lib/srv/app.(*ConnectionsHandler).serveHTTP
	github.com/gravitational/teleport/lib/srv/app/connections_handler.go:701 github.com/gravitational/teleport/lib/srv/app.(*ConnectionsHandler).ServeHTTP
	github.com/gravitational/teleport/lib/auth/middleware.go:790 github.com/gravitational/teleport/lib/auth.(*Middleware).ServeHTTP
	github.com/gravitational/teleport/lib/httplib/httplib.go:104 github.com/gravitational/teleport/lib/httplib.MakeTracingHandler.func1
	net/http/server.go:2171 net/http.HandlerFunc.ServeHTTP
	go.opentelemetry.io/contrib/instrumentation/net/http/[email protected]/handler.go:212 go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*middleware).serveHTTP
	go.opentelemetry.io/contrib/instrumentation/net/http/[email protected]/handler.go:73 go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.NewMiddleware.func1.1
	net/http/server.go:2171 net/http.HandlerFunc.ServeHTTP
	net/http/server.go:3142 net/http.serverHandler.ServeHTTP
	net/http/server.go:2044 net/http.(*conn).serve
	runtime/asm_amd64.s:1695 runtime.goexit

	User Message: ValidationError: 1 validation error detected: Value 'remote-some.randomname@jumo.world-teleport.test-vocal-cougar.eu-dev.awsmmcn.private' at 'roleSessionName' failed to satisfy constraint: Member must have length less than or equal to 64
	status code: 400, request id: 2542a4b3-49c3-4c85-970b-f4ae10de6583" alpnproxy/local_proxy.go:284

Essentially, the error is:

roleSessionName - failed to satisfy constraint: Member must have length less than or equal to 64

The AWS AssumeRole documentation describes this limit.

Looking at the source code:

• When a user is a remote user, its identity username is computed as remote-LOCAL_USERNAME-LOCAL_CLUSTERNAME. The logs above show the same.
• The username is then propagated to the AssumeRole options as RoleSessionName (here as well?).
• Because there's no restriction in the session name applied by Teleport, the AWS API error is propagated to the user.
• In a trusted cluster setup, it's quite easy for the 64 characters limit to be exceeded given that it can include an email address and a hostname, besides the static prefix, therefore, it's reasonable to assume that this issue is more frequent in trusted clusters configurations.

I am happy to open a PR, however I am not sure about the implications of applying some sort of truncation to the role session name given that it's meant to associate CloudTrail events with Teleport users. This possibly needs further consideration.

EDIT: PR opened #44836

Bug details:

• Teleport version: 16.0.4 enterprise
• Recreation steps:

1. tsh login leaf_cluster.example.com --proxy=root.example.com
2. tsh app login aws_app --aws-role SomeIAMRole
3. tsh aws s3 ls

• Debug logs: refer to Current behavior