Quisque actraqum nunc no dolor sit ametaugue dolor. Lorem ipsum dolor sit amet, consyect etur adipiscing elit.
Quisque actraqum nunc no dolor sit ametaugue dolor. Lorem ipsum dolor sit amet, consyect etur adipiscing elit.
Amazon Web Services (AWS) Identity and Access Management (IAM) is one of the things that is often, let’s say, overly complicated, but it is paramount to get it right. Incorrectly applied or overly permissive IAM policies and roles are often factors in cloud incidents.
Correct configuration of IAM permissions is especially important when granting access to one’s AWS Account to third party applications, like ARGOS.
Software as a Service (SaaS) products will typically ask you to create an AWS IAM Role that the SaaS can assume to perform certain operations against the AWS Account.
Side note: If a SaaS requests AWS IAM Access Keys, run. This is a pattern absolutely discouraged by AWS (and often flagged in security reviews).
In order to allow SaaS applications access to your AWS Account it is recommended by AWS to follow the “External ID Pattern” when creating IAM Roles, as described here.
The external ID can be thought of as a “secret string” (it’s NOT a secret though) that ideally only you and the SaaS know about. Whenever someone / something wants to assume that IAM Role they have to also know that External ID, otherwise the request will be denied.
Thing is, this would still allow anybody that knows the IAM Role name, the AWS Account ID and the External ID, to assume the role and its permissions.
Similar to what we showed on Azure in this article here, we want to ensure that the AWS IAM Role can only be assumed by the SaaS itself.
If someone got a hold of the details above (Role name, Account ID, External ID) then they could gain access to your Account. We want to make sure that only requests coming from the SaaS (in our case ARGOS) are approved.
For this we need to add a little statement to the IAM Access Policy for the IAM Role that was created to grant ARGOS access to your AWS Account.
Select “Add inline policy” and pick the “JSON” tab to create a custom, inline IAM policy that gets attached to your IAM Role.
Copy the following snippet into the web form. The IP Address can be found in your ARGOS Dashboard or ask your other SaaS vendors. Replace the IP in the JSON below.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"<your SaaS IP>"
]
}
}
}
]
} Give the policy a name, like “deny-all-except-from-ARGOS” (or whatever name you think is fitting) and create the role.
This policy will now deny all actions, on all resources, unless the request comes from the configured IP.
If someone was to now try to assume this IAM Role from anywhere else, it would not work.
If you are an ARGOS customer, go ahead and configure this on your AWS IAM Roles. We highly recommend this as part of a secure cloud environment, for ARGOS and for every other SaaS you integrate.