aws-as-activate: generate a command (aagg?) for running a program with the AWS_* vars injected

[salewski]

Since aws-as sets, but does not export, the AWS_* environment variables by default, a mechanism is needed by which a subprocess can be run from the current aws-as-enabled shell with the appropriate AWS_* environment variables inject into it.

This feature should take the form of a user-facing shell function that "feels like" a command line app (like aws-as itself). The name should be short and easy to type, since it will need to be specified in front of the real command line the user wishes to invoke.

A full shell session might look something like this:

    # initial state: aws-as is not active in the shell
    $ 

    # user initializes aws-as (and friends)
    $ eval "$(aws-as-activate -s)"
    (-) $

    # user switches to an aws-cli profile for which the creds are already cached
    (-) $ aws-as my-user-prof
    (my-user-prof) $

    # user runs an aws-cli command with the creds for my-user-prof injected into it
    (my-user-prof) $ with-aws-creds aws sts get-caller-identity
    ...

The name with-aws-creds in the above example expresses the idea, but the name itself is too long for regular real-world use. One option would be to use wac, but the phonics are unappealing.

For now, we're going with aagg as the working name for the app, as in "AWS-a-go-go". Yeah, it's dumb, but it's easy to type, and AFAICT, does not collide with any other tools. It is also grep-friendly, which is a feature.

UPDATE (2020-09-13)

Since this issue was originally created, the aws-as project has evolved to depend on aws-vault to a significant degree. When originally written, the only real option for this feature was the creation of an immediate subprocess with the AWS_* cred vars manually injected into it. And casual reading of, for instance, issue #26 might suggest that that is still what is intended. That is not the case, however, so some clarification may be in order.

To best leverage the current implementation, this feature should be implemented "on top of" the aws-vault program's exec subcommand; aws-as should just set it up in such a way that it will be invoked with the in-effect aws-cli profile.

Note that this will create at least two subprocesses: aws-vault will be the immediate child, and the program specified on the aws-as command line will be the grandchild (actually invoked by aws-vault).

[salewski]

From the 'aagg' entry in the aws-as-0.2.0 NEWS file:

 Once you have used 'aws-as' to establish an in-effect aws-cli profile in
 the context of your current shell, the next thing you'll want to do is
 run one or more commands that somehow use the AWS API.

 The 'aagg' command is the primary way to do that. It is a very simple
 wrapper around the 'aws-vault exec' command that sets up the invocation
 using the in-effect profile. As a user, you just prefix the command you
 really want to run with 'aagg':

     aagg YOUR_COMMAND [ARG...]

 The 'aagg' command will build the approprate 'aws-vault' command line to
 use the aws-cli credentials for the in-effect profile. So the above would
 cause an invocation like this:

     /path/to/aws-vault [OPT...] exec IN_EFFECT_PROFILE_NAME -- YOUR_COMMAND [ARG...]

 Here's an example session:

     $ eval "$(aws-as-activate -s)"

     (_) $ aws-as some-prof-name
     [MFA auth, etc, if necessary]

     (some-prof-name) $ aagg aws sts get-caller-identity
     {
          "UserId": "AIDASOMERANDOMESTRING",
          "Account": "111111111111",
          "Arn": "arn:aws:iam::111111111111:user/someuser"
     }

 You can have 'aagg' show you the command it invokes by providing the '-v'
 option:

     (some-prof-name) $ aagg -v aws sts get-caller-identity
     + /path/to/aws-vault exec some-prof-name -- aws sts get-caller-identity
     {
          "UserId": "AIDASOMERANDOMESTRING",
          "Account": "111111111111",
          "Arn": "arn:aws:iam::111111111111:user/someuser"
     }
     + t_estat=0
     + false
     + [[ himxBHs =~ .*x.* ]]
     + set +x

As you would expect, the 'aagg' function and all of it's supporting
machinery get deleted from the current shell process when you invoke
'aws-as-deactivate'.