Failing to assume role via serviceAccount

[mknapcok]

Hi,
I have a problem with assuming role. I'm using this drone pipeline definition:

type: kubernetes
clone:
  depth: 10
kind: pipeline
name: terraform plan - alfa
resources:
  requests:
    cpu: 300
    memory: 300MiB
service_account_name: tf-on-drone-sa
steps:
- image: jmccann/drone-terraform:8.3-1.0.2
  name: tf plan ns_system
  plan: true
  role_arn_to_assume: arn:aws:iam::123456789:role/tf-on-drone-access
  settings:
    actions: validate,plan
    root_dir: eks/environments/alfa/terraform_ns_system
trigger:
  branch:
  - drone-terraform
  event:
  - push

This is run in a CI cluster on aws account for CI. There's kubernetes serviceAccount tf-on-drone-sa which is associated with IAM role on CI account that allows to assume role from ALFA account. This role in ALFA account has permissions to access s3:* and dynamodb:* to have access to a terraform remote state.

After running, I'm getting this error:

To test, if roles are correctly set up, I am running terraform plan from local with ~/.aws/credentials set to assume role from ALFA (with correct IAM permissions to allow assuming ALFA role with my aws user) and it works fine.

Also if I put role_arn_to_assume: arn:aws:iam::123456789:role/tf-on-drone-access under settings: section like this:

settings:
    actions: validate,plan
    role_arn_to_assume: arn:aws:iam::123456789:role/tf-on-drone-access

It's gonna use env PLUGIN_ROLE_ARN_TO_ASSUME in pod and EC2 instance for Kubernetes cluster on which is Drone running as principal will assume ALFA role (with correct IAM permissions to allow assuming ALFA role with default IAM role for CI nodes) and terraform plan works.

[Pajk]

@jmccann To make it a bit more clear here it's important to mention that the plugin is running in a Kubernetes pod on AWS EKS and we need the pod to assume a custom iAM role through iAM roles for service accounts first.

It's using STS Web Identity Federation under the hood, as a result the environment variables AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN are set and they should be used by the AWS SDK first.

It's required if you don't want to allow whole EC2 instance to assume the role from another AWS account. Eg. because there might be other pods running on the instance that should be not authorized to assume the role.

Related AWS Go SDK docs:
https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/#specifying-credentials
https://docs.aws.amazon.com/sdk-for-go/api/aws/credentials/stscreds/