Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for multiple AWS accounts #109

Closed
berniedurfee-ge opened this issue May 4, 2016 · 8 comments
Closed

Add support for multiple AWS accounts #109

berniedurfee-ge opened this issue May 4, 2016 · 8 comments

Comments

@berniedurfee-ge
Copy link
Contributor

When using multiple accounts, it would help to be able to specify an AWS credentials profile in the stack_master.yml file for a particular environment.

https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-multiple-profiles

I think this might mean that instead of a region being the only attribute for where to 'run' the stack, you'd need multiple attributes to describe the 'environment' in which to run the stack. At least the region and the credentials profile to use.

Example

environments:
  production-us:
    region: us-east-1
    profile: prod_profile
  production-eu:
    region: eu-west-1
    profile: prod_profile
  development-us:
    region: us-east-1
    profile: dev_profile
stacks:
  production-us:
    my_stack:
      template: my_prod_stack.cf.json
  production-eu:
    my_stack:
      template: my_prod_stack.cf.json
  development-us:
    my_stack:
      template: my_dev_stack.cf.json
@patrobinson
Copy link
Contributor

I like this idea, but I wonder how we could allow integration to multiple key storage tools. the AWS CLI mechanism of storing keys un-encrypted on disk is not ideal. I use aws-vault for instance, but there are plenty of other tools.

Still, supporting the CLI would be a good first cut.

@stevehodgkiss
Copy link
Contributor

stevehodgkiss commented Jun 7, 2016

I like the concept of environments (to replace region_aliases). It would be nice if StackMaster knew how to get default credentials, but also allow them to be overridden if needed. There are cases where you would want to use a different role in order to apply a change, such as delete an RDS database if the default/usual role doesn't allow that. Teams would need to use the same AWS Vault profile name for this to work well.

One option is to introduce the concept of credential providers, but allow those to be overridden or ignored if credentials already exist in the environment.

environments:
  production-us-east-1:
    region: us-east-1
    credentials:
      profile: myteam-production
      # or
      aws-vault: myteam-production
      # or
      cmd: aws-keys env myteam-production

We'd need some kind of output at the beginning of a SM run to declare which credentials are being used, ENV, or the defined default credentials.

cc @patrobinson @simpsora @andrewjhumphrey

@patrobinson
Copy link
Contributor

patrobinson commented Jun 8, 2016

I don't think stack master should source the credentials for you, that should be the job of the credentials provider (or some wrapper code). I understand aws profiles don't do this, but that's why I prefer aws-vault.

What I would like is some indication as to what account the stack should live in, so if I blindly look at the stack_master.yml file I can easily dissect production from staging, which may or may not be in the same region.

EDIT: I just realised I've completely backtracked on my original comment. But thinking about this more I think we shouldn't couple integration with a credentials store into Stack Master, that seems like a very difficult thing to maintain. Forcing the credentials provider to export to ENV and we pick it up from there seems like a much more straight forward way to manage this.

@flyinbutrs
Copy link
Contributor

I have a patch in the works that implements region_aliases more like environments, but I was really just changing region_aliases to be able to have mutliple aliases for the same region. Is that viable, or would you (the maintainers) prefer to have environments as a separate config key that behaves one way while preserving the region_aliases as they are now.

Also, WRT to environments, one other thing I was working on (though as an optional parameter) to go with this was to have the created stacks prepend the region_alias / environment name. So the config below would create a stack called "prod-app" instead of just app.

stacks:
  prod:
    app:
      template: app.json

@simpsora
Copy link
Contributor

simpsora commented Jun 8, 2016

I agree with @patrobinson -- stack_master's job is to manipulate CloudFormation stacks, not to be concerned with credentials. There are enough different ways to store and pass creds that we can't support them all. The user should be responsible for supplying their credentials by whatever mechanism they wish; stack_master should transparently allow the CLI/SDK to use what the user provided.

I personally use (and advocate the use of) 99designs' excellent aws-vault, but users should be free to use anything else.

@patrobinson
Copy link
Contributor

patrobinson commented Jun 8, 2016

I have a patch in the works that implements region_aliases more like environments, but I was really just changing region_aliases to be able to have mutliple aliases for the same region.

This I tried to do once and it didn't work. I would love this feature.

Also, WRT to environments, one other thing I was working on (though as an optional parameter) to go with this was to have the created stacks prepend the region_alias / environment name.

I think this will need to have a flag to enable this behaviour. Otherwise this breaks everything and is in no way backwards compatible.

@nitehawk
Copy link

Has anything further been done on multi-account capabilities? I'm working on building pieces for stack master and would love to have multi-account capabilities available.

@patrobinson
Copy link
Contributor

@nitehawk more discussion is available here #180

I'm closing this Github issue, the end answer is authentication is not something we want StackMaster to implement. StackMaster does not care if stacks are in a different account, this is a good thing and a bad thing and we're looking to improve the way it handles this going forwards in a few ways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants