IAM cross account #71
Conversation
| @@ -57,6 +57,7 @@ def process(self): | |||
| elb = {} | |||
| output_templates = [] | |||
|
|
|||
| output_templates.append('stacks/iam_out.json') | |||
There was a problem hiding this comment.
Just noticed this needs an if block...
This adds the ability to give limited IAM access to other AWS accounts. We need this so that our build/deploy server can get limited access to the stacks we create even if they are in different accounts. The end result is a IAM role ARN ID which can be assumed by a user in a different account.
This adds an extra bit of code to the AWS api connection utility so that it is possible to assume an IAM role from another account (if your user has the right to). The ARN id of the role to assume is expected as an environment variable.
mattmb
force-pushed
the
iam-cross-account
branch
from
85eea3e
to
fe99dfe
Compare
| { | ||
| "Effect" : "Allow", | ||
| "Principal" : { | ||
| "AWS": "arn:aws:iam::ACCOUNT_NUMBER_HERE:root" |
There was a problem hiding this comment.
Oh I see, this is munged by the config loader.
Rather than doing this and then changing the template inline how about we refer to a CFN Parameter. In the base.json:
"Parameters" : {
"DeployAccountID" : {
"Type" : "Number",
"Description" : "Put a useful desc here"
}
}Then in the stack this bit becomes:
"Principal" : {
"AWS": { "Fn::Join" : ["",
"arn:aws:iam::",
{ "Ref": "DeployAccountID" }
":root"
] }
},I think this makes it clearer - (it means that our python code has to do less at least)
There was a problem hiding this comment.
This is open for discussion if anyone disagrees
There was a problem hiding this comment.
Hmm, that would make the code cleaner. To be clear you'd update the paramaters section from the code and just Ref it in the IAM section?
There was a problem hiding this comment.
I think you just specify the parameters in the API call to CreateStack. Checking
There was a problem hiding this comment.
Parameters:
- parameters (list) – A list of key/value tuples that specify input parameters for the stack.
|
Spoke with @mattmb about this - think we may try to solve another way, leaving bootstrap-cfn purely for AWS provisioning |
|
Setting up the env to be able to deploy to it is part of provisioning to me, but if you can come up with a way that you are feel is better then sounds good 🐎 |
|
@ashb - bootstrap-cfn is about provisioning of AWS services, template-deploy is about deploy. |
|
We were thinking it might be nicer to setup includes. So that we can specify a json file that gets merged with the CF json. That way stuff like this could just be flat file in the template-deploy repo. Only thing I need to check is that Ref'ing the S3 bucket name is possible. |
|
Closing this and tackling the issue with #74 instead. |
This fixes a problem sudoing with fabric so that the limited deploy user is able to run the deploy task over ssh. It also adds the central AWS account as a trusted to access the IAM role neccessary to discover the master and upload to S3. As per ministryofjustice/bootstrap-cfn#71
In order for a central platform to build/deploy to stacks created with this tool we need some AWS API access so that we can:
This PR adds some optional IAM roles that can be assumed from another account. This makes it possible for a deployment script to get the access described above from a limited user in a central AWS account.