hashicorp / hashicorp/packer

Packer's assume role functionality should not error out if the build itself is invoked with the role credentials

Open
#12,110 5 comments 10 reactions 0 assignees View on GitHub
enhancement sync to jira
Dominant language
Go
Stars
15.8k
Forks
3.3k
PR merge metrics
PR metrics pending

Description

## Packer version

```
> packer --version
1.8.4
```

## Description

I created an IAM role (`packer-role`) with the following trust relationship:

```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::275019390123:root"
},
"Action": "sts:AssumeRole",
}
]
}
```

I then assumed the role and set the credentials:

```powershell
$creds=(aws sts assume-role --role-arn arn:aws:iam::275019390123:role/packer-role --role-session-name packer-session | ConvertFrom-Json)

$env:AWS_ACCESS_KEY_ID=$creds.Credentials.AccessKeyId
$env:AWS_SECRET_ACCESS_KEY=$creds.Credentials.SecretAccessKey
$env:AWS_SESSION_TOKEN=$creds.Credentials.SessionToken
```

and confirmed that the new credentials were correctly set:

```powershell
(aws sts get-caller-identity | ConvertFrom-Json).Arn
arn:aws:sts::275019390123:assumed-role/packer-role/packer-session
```

I then tried to run the following Packer build:

```hcl
source "amazon-ebs" "basic-example" {
assume_role {
role_arn = "arn:aws:sts::275019390123:assumed-role/packer-role"
}

region = "us-east-1"
source_ami = "ami-fce3c696"
instance_type = "t2.micro"
ssh_username = "ubuntu"
ami_name = "packer_AWS {{timestamp}}"
}

build {
sources = [
"source.amazon-ebs.basic-example"
]
}
```

this errors out:

> Build 'amazon-ebs.basic-example' errored after 688 milliseconds 339 microseconds: IAM Role (arn:aws:sts::275019390123:assumed-role/packer-role) cannot be assumed.
>
> There are a number of possible causes of this - the most common are:
> * The credentials used in order to assume the role are invalid
> * The credentials do not have appropriate permission to assume the role
> * The role ARN is not valid
>
> Error: NoCredentialProviders: no valid providers in chain. Deprecated.
> For verbose messaging see aws.Config.CredentialsChainVerboseErrors
>

-----------------

## Use Case(s)

My actual use case is a bit more complex.

I have a time consuming Packer build (>1 hour) which is being executed from a Gitlab CI pipeline. The job in the pipeline runs in another account (account B) and has a role associated to it. To run the Packer build in my account, I configured the job to assume the role in my account (account A). This would work fine if it wasn't for the fact that the build is longer than an hour. The sts assume role session chaining is in fact limited to one hour, which means that I can't use this workflow for my build.

I then tried to use the `assume_role` functionality, because my understanding is that by using it Packer would be able to refresh the credentials during the build, which would resolve my problem. The issue however, as illustrated above, is that Packer tries to assume the role even though the role is already assumed.

Should Packer be smart enough to understand that it is running under the assumed role that I specified in the `assume_role` config, and avoid trying to assume it when the build starts?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.