Feature Description
If we use Chariot on a cloud engagement, PS Engineers should have access to the principal Chariot uses to access the client's environment. For AWS, this means a mechanism to assume the IAM role created by the Chariot AWS integration. Engineers could then use the temporary credentials from the assume-role with various cloud command-line tools.
We may also want to consider similar functionality for GCP and Azure, but that will work differently since we use credentials instead of roles for those providers.
Problem
Engineers need CLI access to the customer's cloud environment. It is a small not noticeable piece of friction to ask the client to configure one principal for the engineer and a second principal for Chariot. In most situations, Chariot uses the same access permissions that the engineer needs.
Preferred Solution
I don't know what the best way to achieve this is. We will want IT's input on this one, as providing PS engineers access to the Chariot AWS account sounds like a bad idea.
Perhaps we could do something with the CLI? E.g. a new command that spits out a temporary access key, secret, and session token. It would be easy to paste that into your ~/.aws files and work from there.
Feature Description If we use Chariot on a cloud engagement, PS Engineers should have access to the principal Chariot uses to access the client's environment. For AWS, this means a mechanism to assume the IAM role created by the Chariot AWS integration. Engineers could then use the temporary credentials from the assume-role with various cloud command-line tools.
We may also want to consider similar functionality for GCP and Azure, but that will work differently since we use credentials instead of roles for those providers.
Problem Engineers need CLI access to the customer's cloud environment. It is a small not noticeable piece of friction to ask the client to configure one principal for the engineer and a second principal for Chariot. In most situations, Chariot uses the same access permissions that the engineer needs.
Preferred Solution I don't know what the best way to achieve this is. We will want IT's input on this one, as providing PS engineers access to the Chariot AWS account sounds like a bad idea.
Perhaps we could do something with the CLI? E.g. a new command that spits out a temporary access key, secret, and session token. It would be easy to paste that into your
~/.awsfiles and work from there.