Allow teleport AWS access to work with aws tooling

[programmerq]

What

Currently, you must use tsh aws to access aws resources, but there are lots of usecases where it is important to be able to use unmodified applications and tools that are designed to work with aws directly.

How

I imagine it would be a similar workflow to accessing a db via database access or a kube cluster via kubernetes access. There would be a command that "logs in" to the aws console, and that writes out a config file or environment variables that other tools can take advantage of.

Why

To allow teleport users to take advantage of the vast existing ecosystem of tools that work with aws.

Workaround

none

gz#4128

[stevenGravy]

this pr should be handling this. https://github.com/gravitational/teleport/pull/10025

[evilmog]

This PR will not handle it, some of our tools require raw access key and secrets. Specifically penetration testing tools that would not be able to use an AWS proxy. Ideal operation would be outputting a ~/.aws/credentials file with short lived API keys for direct connections bypassing teleport entirely.

[evilmog]

If it helps we are an enterprise support customer

[evilmog]

Alternatively a method to exchange the x509 for AWS API Credentials for certain legacy tools would be handy.

[greedy52]

we can easily generate temporary tokens to be used in ~/.aws/credentials. you can kinda do that today by tsh aws sts assume-role xxx if you know what parameters to set. we can make that a special tsh command if needed. Though, bypassing teleport means no auditing (in teleport).

[greedy52]

Got a suggestion from community slack, we can probably launch a subprocess with temporary credentials. Could be something like tsh aws exec my-custom-aws-progrom a b c, and tsh can get tmp credentials from assume-role, set it in env, prints when session will expire, and then launch my-custom-aws-progrom a b c

[dancmeyers]

Yeah, in that way it would work similarly to aws-vault, but getting temporary credentials assigned by Teleport. As you say, that would mean no auditing, which could be a problem for some folks, but I don't see a way around that with various legacy tools. And it would be similar to a kubectl port-forward, in that Teleport would log that it was done, but not what then happened over that connection/with those credentials.

Depending on how far you want to go, you could also add an extra parameter in the role spec, so that as well as aws_role_arns there is a parameter like aws_local_credentials or similar, which is a boolean, and specifies whether the holder of the role is allowed to obtain temporary credentials to run commands locally, bypassing Teleport auditing. If it defaults false if not set then current behaviour is maintained and users can choose to define a role where it is true which perhaps a more limited subset of people in their org can access.

[evilmog]

That would be awesome

On Thu., Mar. 17, 2022, 2:59 a.m. Dan Meyers, @.***> wrote:

Yeah, in that way it would work similarly to aws-vault https://github.com/99designs/aws-vault, but getting temporary credentials assigned by Teleport. As you say, that would mean no auditing, which could be a problem for some folks, but I don't see a way around that with various legacy tools. And it would be similar to a kubectl port-forward, in that Teleport would log that it was done, but not what then happened over that connection/with those credentials.

Depending on how far you want to go, you could also add an extra parameter in the role spec, so that as well as aws_role_arns there is a parameter like aws_local_credentials or similar, which is a boolean, and specifies whether the holder of the role is allowed to obtain temporary credentials to run commands locally, bypassing Teleport auditing. If it defaults false if not set then current behaviour is maintained and users can choose to define a role where it is true which perhaps a more limited subset of people in their org can access.

— Reply to this email directly, view it on GitHub https://github.com/gravitational/teleport/issues/10441#issuecomment-1070566492, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZBQUXFAWFVMBXSMWPDC53VALYA3ANCNFSM5OV4R7LA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[strideynet]

Potentially resolved with AWS roles anywhere and Workload ID

https://github.com/gravitational/teleport/issues/37329

[userhas404d]

I'm poking at this today in an attempt to see if I can make my org's teleport implementation jive with granted, but couldn't the same end result be accomplished if teleport was able to be credential_process compliant? https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-sourcing-external.html

edit: missed this in the thread above..

Though, bypassing teleport means no auditing (in teleport).

[greedy52]

I'm poking at this today in an attempt to see if I can make my org's teleport implementation jive with granted, but couldn't the same end result be accomplished if teleport was able to be credential_process compliant? https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-sourcing-external.html

edit: missed this in the thread above..

Though, bypassing teleport means no auditing (in teleport).

You can use credential_process with Teleport to assume another IAM role in dire situations. When tsh aws sts assume-role, it gives real credentials. On very rare occasions, we recommended users to do this way if the tooling doesn't work with tsh's local proxy anyway.

Sample AWS credentials:

[tsh]
credential_process = /Users/stevehuang/tsh_assume_role_code_commit.sh

Sample script

$ cat /Users/stevehuang/tsh_assume_role_code_commit.sh
#!/bin/bash

# An AWS role that `tsh aws` can assume
code_commit_role="arn:aws:iam::123456789012:role/steve-codecommit"

# Make sure you already `tsh app login` the target AWS app or maybe somehow inject that in this script
# See https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-sourcing-external.html
tsh aws sts assume-role --role-arn $code_commit_role --role-session-name teleport-codecommit | jq -r '.Credentials + {"Version":1}'

Not only this requires an extra IAM role for the original IAM role to assume, but also the assumed IAM role will bypass Teleport.

[userhas404d]

Thanks for this @greedy52! Maybe this needs a separate issue but ultimately my goal is to have access to the firefox tab containers that granted uses to isolate multiple/separate AWS console sessions. More details here. I would expect I would be able to do that with the credentials of the role the teleport session is already using (sans an additional assume role step).

example credential process script for this:

#!/bin/bash

tsh apps login <my_app> --aws-role <my_role> &> /dev/null
# https://awscli.amazonaws.com/v2/documentation/api/latest/reference/configure/export-credentials.html
tsh aws configure export-credentials

Unfortunately, I'm hitting this issue when attempting this. Unclear at this stage if this is an issue with granted or a fundamental misunderstanding on my part with how teleport is managing the AWS session.