Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

(SEC403) Building AWS Partner Applications Using IAM Roles | AWS re:Invent 2014


Published on

AWS Identity and Access Management (IAM) roles are powerful primitives you can use to build applications that can access a broad range of data without collecting databases of credentials. This session explains how to model applications that are granted access to large numbers of AWS accounts through the use of IAM roles. It covers advanced role permission modeling and sample implementations.

Published in: Technology
  • Be the first to comment

(SEC403) Building AWS Partner Applications Using IAM Roles | AWS re:Invent 2014

  1. 1. © 2014, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in partwithout the express consent of, Inc. November 13, 2014 | Las Vegas SEC403Building AWS Partner Applications Using IAM Roles Bob Van Zant, Bracket Computing
  2. 2. Resources •Code samples: – •IAM policy helper: –
  3. 3. Use cases •Cloud management platform •Log analysis •Cloud spend analysis •Operating across more than one AWS account •Generalized: AWS applications that access other AWS accounts
  4. 4. Anti-patterns •Ask for access key IDand secret access key •Asking users to trust you more than they should –“Create an admin user and send us the creds” •Eager IAM policies –action: *
  5. 5. Requirements •Act within another AWS account •Take on subset of permissions to act within AWS •Cannot be required to persist a secret(s)
  6. 6. AssumeRole API call “Returns a set of temporary security credentials that you can use to access AWS resources that you might not normally have access to.Typically, you use AssumeRolefor cross-account access or federation.”
  7. 7. DescribeInstances example •Given account IDand region •Print instance names and status •Setup required: –IAM role in customer account –Role trust in customer account
  8. 8. To the console
  9. 9. AssumeRole Parameters
  10. 10. Easy ones •Duration: validity period for creds, 900-3600sec –Go shorter with IAM policy variables •RoleArn: The ARN of the role you’re assuming •SerialNumber:For an MFA device –Hardware serial number for gemalto –ARN for virtual •arn:aws:iam::<account id>:mfa/<iamuser> •TokenCode: Code from MFA device
  11. 11. Policy •JSON string with valid IAM policy up to 2048 bytes •Use this to further restrict permissions by scoping down the policy •Imagine a logical and of the role’s policies with this new policy. –i.e. May only be used to restrict access of the role being assumed
  12. 12. To the console
  13. 13. RoleSessionName •Between 2 and 32 characters long •Fairly restrictive character set: –^[w+=,.@-]{2,32}$ •Useful for auditing •Shows up in AWS CloudTraillogs (i.e. name wisely)… session_name= “Hi-Mom” sts_conn.assume_role(role_arn, session_name)
  14. 14. CloudTrail in your account 'requestParameters': { ‘durationSeconds': 2011, 'roleArn': ‘arn:…role/role-name’, 'roleSessionName': ‘Hi-Mom’},
  15. 15. CloudTrail in customer account 'userIdentity': { 'accessKeyId': 'ASIA…', ‘accountId': '111122223333', 'arn': ‘arn:…:assumed-role/ROLE-NAME/Hi-Mom’
  16. 16. Auditing Results Time: 10/31/2014 13:05:19.000 RoleArn:arn:aws:iam::111111111111:role/brkt-readonly RoleSessionName:adm-hub-mani Who:arn:aws:sts::999999999999:assumed-role/prod-brkt-net- hub-web/i-30e01eda Time: 10/31/2014 15:07:59.000 RoleArn:arn:aws:iam::111111111112:role/brkt-readonly RoleSessionName:adm-hub-krishnan Who:arn:aws:sts::999999999999:assumed-role/prod-brkt-net- hub-web/i-56e7e0b8
  17. 17. Auditing _sourceCategory=AWS_EAGLE | json “eventName", “requestParameters.durationSeconds", “requestParameters.roleArn", “requestParameters.roleSessionName", "userIdentity.arn" | where eventName = "AssumeRole" | where %"requestParameters.roleSessionName" matches "adm-*" •Example Sumo Logic query
  18. 18. ExternalId •A pre-shared secret between you and your customer •String from 2-1224 bytes long •Used to prevent “confused deputy” problem “A confused deputy is a computer program that is innocently fooled by some other party into misusing its authority.”
  19. 19. Let’s confuse the deputy •Assume a cloud management platform •Customers bring their own AWS account
  20. 20. Getting confused
  21. 21. Confusion is imminent
  22. 22. Deputy confused Imageisinpublicdomain.Obtainedfrom
  23. 23. We’ve been owned •Attacker has obtained a login to our platform •Attacker has given a legitimate customer’s AWS ID(the victim’s) instead of his own •Attacker can now use our platform to view and act within the victim’s AWS account. •Oops.
  24. 24. What went wrong? •We never verified that our user owned the AWS account in question •AWS provides the External IDparameters,which lets us do that
  25. 25. Deputy not confused
  26. 26. Prevent that attack •Customer brings 12-digit IDon signup •You generate an external IDand hand to customer •Customer sets up roles and trust, including the external IDyou specified •Attack mitigated –Attacker can only leverage your platform to takeover customer account if they have already compromised the customer account and can modify the trust policy
  27. 27. Are you vulnerable? •Do you allow customers to bring their own account? •Are you using external IDas described here? •If not, your customers are at risk. •It’s your fault.
  28. 28. Complete example
  29. 29. Notch it up •Let’s build our cloud management platform on AWS •Use Amazon EC2 instance profiles to seed access •Instance profile should reference an access policy that is again least privilege •The more privileged an instance, the further from users/attackers it should be
  30. 30. Sample architecture Harder to attack; allow increasing privilege
  31. 31. To the console
  32. 32.