Support for specifying AWS profile by name?

[kwerey]

Hi Heptio crew,

This tool is neat! Thanks!

I wanted to ask:

1. Is there currently support for specifying an AWS profile by name in the tool? As far as I can tell that isn't possible currently, - is that right?

2. If not, do you have any interest in supporting that feature?

My use case is "we operate in many AWS accounts, and want it to be impossible to auth into the wrong one", so being able to be explicit about which account a cluster belongs to in a configuration file is valuable.

It seems like you could optionally pass a profile_name parameter to the Go SDK's NewSessionWithOptions function with minimal disruption to anything else https://github.com/heptio/authenticator/blob/master/pkg/token/token.go#L149. I'm curious if it's something you've thought about adding/if you'd welcome a PR to add it.

thanks
Nikki

[christopherhein]

The go SDK supports the standard AWS credentials chain so using the AWS_DEFAULT_PROFILE environment variable should provide you what you are looking for.

It would look something like:

export AWS_DEFAULT_PROFILE=foo
heptio-authenticator-aws token

[kwerey]

Thanks, I'm aware of that. My use case is that my team works with environments split across many different AWS environments, so it's handy to be able to explicitly set AWS profiles by name in config files, rather than having to keep updating env vars!

[mumoshu]

I believe I understand your use-case.

For tools other than authenticator, I even wanted to share AWS_DEFAULT_REGION across my colleagues for motivation similar to yours, but I eventually ended up just using direnv.

Of course you can use any tool other than direnv for that, but in general, achieving the goal out of authenticator has a benefit that:

• You can define and document a whole "environment" within a single file(.envrc in this specific case). It can be said "whole" when it contains not only authenticator config but everything.

Also I have a few concerns on supporting it within authenticator:

• When I have AWS_PROFILE explicitly set, why authenticator prefers the profile specified in the config yaml?
• How can I override the AWS profile specified in the config at runtime? I can't help expecting it to be a "default" value which can be overridden at runtime.
  • The user wants to organize his/her AWS profiles by his/her own convention.

That being said, yes, the suggest feature would definitely be handy! But I believe we outgrow it given the edge-cases I've noted above.

WDYT?

[nckturner]

@kwerey Is it helpful that with 1.10 support merged, you can specify a user in your kubeconfig like so:

users:
  - name: kubernetes-admin
    user:
      exec:
        command: /path/to/heptio-authenticator-aws
        args:
          - token
          - --cluster-id
          - test
          - --role
          - arn:aws:iam::123456789876:role/KubernetesRole
        env:
          - name: AWS_PROFILE
            value: dev
        apiVersion: client.authentication.k8s.io/v1alpha1

Where you can specify the usual environment variables, i.e. AWS_PROFILE, in that file? This configuration would take the credentials from the dev profile in your aws config file, then use those credentials to assume KubernetesRole.

[kwerey]

Sorry for the slow response on this one @mumoshu , I got pulled away from container work for a while!

Direnv or other tools to just streamline configuring the environment is a neat way of avoiding this - but because we have a relatively wide pool of people with diverse environments involved in maintaining container environments in my shop, we can't make a one-size-fits-all set of environment config easily, whereas we can standardise profile names and specify them in config self-contained without having to use third party tools or "and now copy&paste this into your bash profile". Specifying account/region for AWS config-as-code resources also seems like a valuable guarantee to me that prod config will only ever get applied to the relevant prod environment...

Hmm. I don't have the same expectations as you about priority/overrides. Mine are set by Boto (the python SDK), which is the first tool I used for interacting with AWS APIs. That has this order of priority for credentials. Top to bottom as highest priority to lowest:

Passing credentials as parameters in the boto.client() method
Passing credentials as parameters when creating a Session object
Environment variables
Shared credential file (~/.aws/credentials)
AWS config file (~/.aws/config)
Assume Role provider
Boto2 config file (/etc/boto.cfg and ~/.boto)
Instance metadata service on an Amazon EC2 instance that has an IAM role configured.

That ordering makes a lot of sense to me - use explicit values if specified, if not use a well-known order to determine which creds get used by preference. I assume the go SDK does the same - if you explicitly set a value, it gets used, if not, default to the environment.

The thing I see as a bigger drawback of wanting to specify named credentials for AWS accounts in config is actually something else: it can trip you up when you want to move from individual hosts doing orchestration work, to running the work from Jenkins or another CI tool that runs on an EC2 instance and using an IAM role.

We ran into this using Ansible for build/orchestration, and when we moved those workloads into a fully CI integrated stack we ended up kinda hackishly using sed to comment out profile names so let the instance profile creds take priority!

Anyway, if this isn't part of your plan at the moment that makes sense.

@nckturner - thanks, will take a look.

[nckturner]

Awesome, let us know if it doesn't support your use-case.

[vchan2002]

Thanks for pointing that out @nckturner! I actually stumbled upon this as a solution for for setting up kubeconfig for EKS. Specifying the profile is especially important... otherwise, it might pull the wrong IAM credentials and would not auth accordingly.