search

gravitational / teleport

The easiest, and most secure way to access and protect all of your infrastructure.
https://goteleport.com
GNU Affero General Public License v3.0
16.97k stars 1.71k forks source link

Add Support for Cloud Applications in Teleport Machine ID #35746

Open programmerq opened 6 months ago

programmerq commented 6 months ago

What would you like Teleport to do?

Add support within Teleport Machine ID's configuration to specify cloud roles for AWS, Azure, and GCP applications analogous to the --aws-role, --azure-identity, and --gcp-service-account flags in tsh. This will allow Machine IDs to correctly generate identities for cloud applications, which is currently resulting in the error "selected app X is not an AWS application" when running tbot proxy aws.

What problem does this solve?

When attempting to use tbot proxy aws with a cloud application defined in tbot's configuration (outputs/destinations), it fails with an error indicating that the selected app is not recognized as a cloud application. This prevents automation scenarios such as accessing AWS CLI through Teleport in CI/CD pipelines using Teleport's Machine ID feature.

The error selected app "aws-client" is not an AWS application suggests that the current implementation of Teleport Machine ID may not support specifying cloud roles needed for cloud applications.

If a workaround exists, please include it.

Currently, there is no known workaround for accessing cloud applications via Teleport Machine ID with tbot proxy. A manual login using tsh with interactive users seems to be the only way to access these cloud apps, which doesn't solve the use case for automated access in CI/CD environments.

Additional info

Click to expand When `tbot` or `tsh` generate a credential for an app, it creates a user certificate that has the name of the app in question embedded in the x509 data. For example, the x509 data for an app called "grafana" might include the following: ``` 1.3.9999.1.6=grafana.teleport.example.com, 1.3.9999.1.10=grafana ``` For an AWS app, it has those same references, but it also requires info about the AWS role. ``` 1.3.9999.1.6=awscli.teleport.example.com, 1.3.9999.1.10=awscli, 1.3.9999.1.11=arn:aws:iam::000000000000:role/poweruser, 1.3.9999.1.12=arn:aws:iam::000000000000:role/poweruser, 1.3.9999.1.12=arn:aws:iam::000000000000:role/readonly ``` The `1.3.9999.1.11` value specifies the requested role. `tbot` doesn't include that bit since there isn't a way to specify it in the config file. It does include the `1.3.9999.1.12` entries. Those are just the roles that are allowed to be requested. When `tbot proxy aws` is instructed to use that cert, the missing `1.3.9999.1.11` field makes it think that it is a non-AWS app, resulting in the error message about the app not being an AWS app. To see the Subject of the x509 cert for an app: ``` openssl x509 -noout -subject -in ~/.tsh/keys/teleport.example.com/jeff-app/teleport.example.com/awscli-x509.pem ```
strideynet commented 6 months ago

I definitely agree we're lacking functionality here - but I'd love to understand the use case here a little better. There's often existing ways of allowing a machine to access one of these cloud platforms already (e.g https://cloud.google.com/iam/docs/workload-identity-federation or https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html).

I'd like to understand why a user needs, or wants, Teleport to implement this functionality. Is it a case of their platform not providing an identity that can be exchanged for one on the cloud platform, or are we providing some level of additional access control ? or is this a case of consolidating access onto one platform? Understanding the motivation here may let us tailor this solution a little better.

aprohorov-callsign commented 6 months ago

Hey @strideynet ,

yeah, I think the main point is to keep all control in one place. Users use Teleport to proxy requests to AWS (for CLI and Terraform) but if we want to apply Terraform through a pipeline we have to extend infrastructure with OIDC to allow robot access.

It's not directly related to the current feature (issue), but for me ideal solution for robot access is to have the ability to delegate some user permissions. Similar to AWS SSO flow or any streaming platform (like Netflix). Tbot attempts to login and gets a unique URL (device code), then a user should follow that link and authorize on the server and approve the request. After that tbot get access with the approved user permissions. So if user A has access only to AWS account A, any CI job he'd triggered couldn't get access to any other AWS account (while the user didn't extend his access by additional Teleport request)