Given that malicious actors and cyber attacks have become commonplace, all risks must be minimized when granting external access to your cloud. While most organizations are aware of the need for vigilance, they aren\u2019t sure how.<\/p>\n\n\n\n
There are many best practices to follow for an AWS integration, but today we\u2019ll be focusing on Assume Role, aka letting third parties assume an IAM role for limited session duration. It works best if you\u2019re using an Identity Provider with AWS. Let\u2019s dive right in.<\/p>\n\n\n\n
Assume Role provides a set of temporary security credentials to access AWS resources you might not have access to in normal conditions. These temporary credentials consist of a security token, an access key ID, and a secret access key.<\/p>\n\n\n\n
The credentials generated by Assume Role can be used in making API calls to AWS services with the following exception: calling the AWS STS GetFederationToken or GetSessionToken API operations.<\/p>\n\n\n\n
When you need to grant external access to a third-party service, it can assume an IAM role to request temporary credentials and access to your AWS resources for a specified session duration. This way, you won\u2019t need to share long-term credentials like a password or access key associated with it with third parties.<\/p>\n\n\n\n
You can securely delegate access to users, services, or applications that normally don\u2019t have access to your resources. For example, you might grant access to your account to a third-party service so that it can operate audits on your resources.<\/p>\n\n\n\n
You can use an Assume Role to obtain temporary security credentials. That way, you reduce the risk of accidentally exposing your long-term credentials.<\/p>\n\n\n\n
Session duration times for the temporary credentials are configurable. AWS Security Token Service (STS) designates default session times for the credentials. They expire after passing the specified time limit.<\/p>\n\n\n\n
With Assume Role, third parties can only access temporary credentials. Combined with an external ID condition, using Assume Role for third-party integrations improves security hygiene and prevents unauthorized access.<\/p>\n\n\n\n
If you need to stop an assumed IAM role from accessing your resources, you can revoke the session permissions<\/a> from a role.<\/p>\n\n\n\n First things first, AWS provides access to AWS resources through IAM roles. That means, in order to access a resource in an AWS account, you need an IAM role with the necessary permissions. The process is better understood if we pass through the tip of the iceberg. Let\u2019s break it down into key concepts.<\/p>\n\n\n\n Resource: A resource in AWS is an object within a service such as an IAM user, an Amazon S3 bucket, or an Amazon EC2 instance.<\/p>\n\n\n\n AWS Identity Access Management (IAM) helps you control and define who is authenticated (successfully signed in) and authorized (have proper permissions) to access and use your resources. Requested operations can be performed after AWS approves the request. <\/p>\n\n\n\n An IAM role<\/a> is an IAM identity that you can create with specific permissions. It provides a mechanism to grant access to your AWS resources without needing to give away your long-term credentials. Unlike an IAM User, which is associable with one person, an IAM role is assumable by anyone. <\/p>\n\n\n\n A recommended best practice when granting resource access to a third party is using an IAM role with an external ID. An external ID is a unique identifier that you can pass to the AssumeRole API of the Security Token Service. You can use an external ID in the condition element of a role\u2019s trust policy. That way, only someone with the exact external ID can assume the Role.<\/p>\n\n\n\n To assume a role, you need to use the Security Token Service (STS) that generates the temporary credentials to use the Role. When you assume a role, you receive credentials with which you can make API calls. These credentials allow you to act in the assumed Role until they expire. They are separate from your original credentials, so you can use both simultaneously for different API calls. They also look different as in the following schema.<\/p>\n\n\n\n Using an external ID as an additional parameter when assuming a role is optional but recommended to prevent unauthorized access. It is advised, especially when you need to give a third-party access to your AWS resources. I\u2019ll go over a scenario to demonstrate the process<\/a>.<\/p>\n\n\n\n So, even if you use the Assume Role, an unauthorized user could gain access to your resources. That\u2019s called the confused deputy problem<\/a>.<\/p>\n\n\n\n An unauthorized user could exploit the confused deputy problem to access your AWS resources. <\/p>\n\n\n\n When you start using the partner\u2019s service, you give them the ARN of AWS1:ExampleRole to assume the Role. Example Corp uses that ARN to obtain temporary security credentials to access resources in your AWS account. In this scenario, you\u2019re entrusting the partner as a \u201cdeputy\u201d that can act on your behalf.<\/p>\n\n\n\n Another customer of Example Corp uses the same service. Let\u2019s assume that this other customer learned or guessed the ARN of AWS1:Example. So, that customer also gives the ARN of AWS1:ExampleRole to the partner to assume the Role. When the customer asks Example Corp to access the AWS resources in \u201cits\u201d account, Example Corp will use the AWS1:ExampleRole to access your resources.<\/p>\n\n\n\n This way, the other customer could gain access to your AWS resources as it tricked Example Corp into unknowingly acting on your resources. And now, the Example Corp is a \u201cconfused\u201d deputy.<\/p>\n\n\n\n The cause of vulnerability here is that Example Corp, as the IAM User, did not pass an external ID when assuming a role.<\/p>\n\n\n\n JumpCloud SAML single sign-on (SSO) gives your users convenient and secure access to AWS with a single set of credentials for a true single sign-on experience and automated user and group management. The JumpCloud AWS IAM Identity Center connector<\/a> can also automate and centralize user and group management for provisioning, de-provisioning, and updating of AWS users and groups from JumpCloud via the SSO solution.<\/p>\n\n\n\n You can try JumpCloud for free<\/a> to determine if it\u2019s right for your organization.\u00a0Our customers tell us that asset management is also important<\/a> for security and IT operations. JumpCloud is enhancing its platform<\/a> to unify SaaS, IT security, and asset management.<\/p>\n","protected":false},"excerpt":{"rendered":" Using AWS Assume Role is a secure method when integrating your account with third parties. Here’s everything (simplified) to get started with Assume Role.<\/p>\n","protected":false},"author":229,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_oasis_is_in_workflow":0,"_oasis_original":0,"_oasis_task_priority":"","inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"collection":[2780],"platform":[],"funnel_stage":[3016],"coauthors":[3218,2535],"acf":[],"yoast_head":"\nLaying Down The Basics<\/h2>\n\n\n\n
AWS Identity Access Management (IAM):<\/h3>\n\n\n\n
IAM Roles<\/h3>\n\n\n\n
\n
External ID<\/h3>\n\n\n\n
Long-Term Credentials vs. Temporary Credentials<\/h3>\n\n\n\n
Integration with Assume Role & External ID Combination<\/h3>\n\n\n\n
\n
\n
Integrate AWS IAM with JumpCloud<\/h2>\n\n\n\n