AWS Plugins using IAM Roles (No AWS Keys)

Drone Support
1

Hi,

I have a private drone server on AWS in which I’d like to use IAM roles to authenticate with various cloud services, such as S3 (so I don’t have to manage individual keys).

However, two of the S3 plugins (drone-s3 and drone-s3-sync) will fail if no keys are provided. I haven’t checked all AWS plugins though so this issue may also be present elsewhere.

I was wondering if simply ignoring the check for aws keys would be an acceptable solution (like here and in here)? I see that some plugins used to check for a verified yaml file for security reasons, but it seems that drone sign is not supported anymore.

I’m also wondering if this solution could present some risks, as in a public repo anyone could open a pull request and add a malicious step that abuses the instance IAM roles. My use is for private repositories, so for me that’s not a concern, but is there a general solution to avoid plugins giving too much permissions to “malicious pull requests”?

In any case I’d be happy to open multiple PRs addressing this, as I’m making use of several AWS plugins myself.

Cheers

2

IMO, I think the yaml should explicitly say iam_roles: true # default false before it tries anything using IAM roles.

By default AWS plugins should require the access key and secret key.

3

I’m afraid this might actually confuse users.

The default behavior for all official AWS tools I know of is to try multiple different authentication methods. So users familiar with the AWS environment will likely expect drone plugins to adopt the same behavior.

E.g., from the official aws-cli:

The AWS CLI looks for credentials and configuration settings in the following order:

Command line options – region, output format and profile can be specified as command options to override default settings.

Environment variables – AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN.

The AWS credentials file – located at ~/.aws/credentials on Linux, macOS, or Unix, or at C:\Users\USERNAME .aws\credentials on Windows. This file can contain multiple named profiles in addition to a default profile.

The CLI configuration file – typically located at ~/.aws/config on Linux, macOS, or Unix, or at C:\Users\USERNAME .aws\config on Windows. This file can contain a default profile, named profiles, and CLI specific configuration parameters for each.

Container credentials – provided by Amazon Elastic Container Service on container instances when you assign a role to your task.

Instance profile credentials – these credentials can be used on EC2 instances with an assigned instance role, and are delivered through the Amazon EC2 metadata service.

Boto3 has a similar approach:

The mechanism in which boto3 looks for credentials is to search through a list of possible locations and stop as soon as it finds credentials. The order in which Boto3 searches for credentials is:

Passing credentials as parameters in the boto.client() method
Passing credentials as parameters when creating a Session object
Environment variables
Shared credential file (~/.aws/credentials)
AWS config file (~/.aws/config)
Assume Role provider
Boto2 config file (/etc/boto.cfg and ~/.boto)
Instance metadata service on an Amazon EC2 instance that has an IAM role configured.

Same for the aws-go sdk.

So I’d argue that the drone plugins should leave authentication implementation to the SDKs, instead of implementing its own rules.

1 Like