Content Comparison

It is a best practice to assume roles that are granted just the required privileges to perform an action. If the customer does not want to use their own AWS user to perform these actions required by the collector (because it has far more privileges than required), they can use this option. Note that this option requires the use of AWS account credentials. To avoid sharing those credentials, check the Cross Account option below.

The customer must attach the required policies in AWS to the role that is going to be assumed. For more information about the AssumeRole feature, check the AWS documentation.

Regarding configuration, these are the fields required to use this way of authentication:

...,
"credentials":{
  "access_key": "<CUSTOMER_AWS_ACCOUNT_ACCESS_KEY>",
  "access_secret": "<CUSTOMER_AWS_ACCOUNT_SECRET_ACCESS_KEY>",
  "base_assume_role": "arn:aws:iam::<CUSTOMER_AWS_ACCOUNT_ID>:role/<ROLE_TO_BE_ASSUMED>"
}
...,

• access_key is the Access Key ID provided by AWS, during the user creation process, to those users that ask for programmatic access.

• access_secret is the Secret Access Key provided by AWS, during the user creation process, to those users that ask for programmatic access. This value is shown once, so it must be saved upon creation.

• base_assume_role is the ARN of the role that is going to be assumed by the user authenticated with the parameters above, access_key and access_secret. This role has to be properly granted to allow the actions the collector is going to perform.

If the customer does not want to share their credentials with Devo, there is another way to run the collector. It is called Cross Account and AssumeRole functionality should be used in this case and it is explained step by step in the next link: https://docs.devo.com/space/latest/94655615/AWS (S3%2BSQS) collector#Enabling-SQS-and-S3-access-using-a-cross-account-IAM-role

Besides, some parameters must be added to the configuration file (config.json or equivalent config.yaml for on-prem). In the credentials section, instead of sharing access_key and access_secret, these other parameters must be used:

...,
"credentials":{
  "base_assume_role": "arn:aws:iam::<BASE_SYSTEM_AWS_ACCOUNT_ID>:role/<BASE_SYSTEM_ROLE>",
  "target_assume_role": "arn:aws:iam::<CUSTOMER_AWS_ACCOUNT_ID>:role/<CUSTOMER_ROLE_TO_BE_ASSUMED>",
  "assume_role_external_id": "<OPTIONAL__ANY_STRING_YOU_WANT>"
}
...,

• base_assume_role is the ARN of the role that is going to be assumed by the profile bound to the machine/instance where the collector is running. As explained in the link above, this role is going to be trusted by the customer’s AWS account, so it can assume the role in the target account. That role assumed from the customer’s account will allow the collection of data without the need of sharing the credentials. This role already exists in Devo’s AWS account and to deploy the collector on Devo’s Collector Server its value must be arn:aws:iam::837131528613:role/devo-xaccount-cs-role.

• target_assume_role is the ARN of the role in the customer’s AWS account. That role will allow the collector to have access to the resources specified in that role. To keep your data secure, please, use policies that grant just the necessary permissions.

• assume_role_external_id is an (optional) parameter to add more security to this Cross Account operation. This value should be a string added in the request to assume the customer’s role.