search

sul-dlss-deprecated / rialto

RIALTO - Stanford Libraries' Research Intelligence System
https://library.stanford.edu/projects/rialto
5 stars 1 forks source link

create iam role for ec2 instance for RIALTO ingest service to connect to SNS #111

Closed cmharlow closed 6 years ago

cmharlow commented 6 years ago

seeing if this can be done via vpc settings. otherwise, requires ops to give AWS DLSS Dev Env DeveloperRole access to IAM Roles list + create

cmharlow commented 6 years ago

Question posed in dlss operations channel on slack.

kamchan commented 6 years ago

we added iam.CreateRole so please give it another shot when you get a chance.

cmharlow commented 6 years ago

checking now!

cmharlow commented 6 years ago

error now: User: arn:aws:sts::418214828013:assumed-role/DevelopersRole/cmharlow is not authorized to perform: iam:ListPolicies on resource: policy path /

kamchan commented 6 years ago

ok, added iam:ListPolicies, onto the next error :)

cmharlow commented 6 years ago

lol sorry: User: arn:aws:sts::418214828013:assumed-role/DevelopersRole/cmharlow is not authorized to perform: iam:CreateInstanceProfile

cmharlow commented 6 years ago

(sorry, i hope you guys only have to go through this once, and other devs will benefit)

kamchan commented 6 years ago

iam:CreateInstanceProfile has been added. @jonrober has more thoughts on this and will update this ticket with them soon.

jonrober commented 6 years ago

Generally, this sounds like it's in order to let the sul-dlss-development account work with an SNS topic from another account? If so, that's what I was talking about a few days ago on #operations, about how the design isn't really meant for doing cross-account work. Everything should normally just be in the account for the environment it's in. There'll be some exceptions of course, where you you have to work on resources that are outside of our normal things. Especially when we're still not fully in on the new environment. So you have the permission, but please keep things in a single environment with you can (and definitely don't do cross-environment roles).

Otherwise just to mention, https://policysim.aws.amazon.com/home/index.jsp might help you with figuring out when you need permissions.

cmharlow commented 6 years ago

@jonrober none of this should be cross-account work, fyi. the SNS topic is in the AWS dlss dev environment; the VPC with the EC2 instance & the Neptune instance are in the AWS dlss dev env.

cmharlow commented 6 years ago

I can confirm the above, actually.

cmharlow commented 6 years ago

I believe what is happening is the following: for code in our EC2 instance to be able to write to a topic in SNS, all in the same dev environment, the EC2 instance needs an AWS role with attached SNS write-enabled policy. I've not found a work around to this. It seems poor practice, even in a development environment, to give the EC2 instance my developerRole credentials to support the call, but I can do that if that is what you guys would prefer.

jonrober commented 6 years ago

No, that's fine here. The problem on my end is that we're still coming up to speed on AWS with a lot going on, I don't have a lot of knowledge of specifically what you're doing, and I've been doing a lot of cross-account roles for the initial setup. So in my head roles are mostly used for that, even if I know better. Sorry about assuming there again, I need to keep in mind.

cmharlow commented 6 years ago

Gotcha, no prob!

cmharlow commented 6 years ago

Alright, last problem, i hope: able to create role, trying to assign to EC2 instance, get this error: User: arn:aws:sts::418214828013:assumed-role/DevelopersRole/cmharlow is not authorized to perform: iam:ListInstanceProfiles on resource: arn:aws:iam::418214828013:instance-profile/

cmharlow commented 6 years ago

Appears to be done. Now needs testing but a role with sns write policies was associated to an instance profile that was then associated to an ec2 instance.