Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permissions check erroneously fails on self-hosted runner using an EC2 instance profile #83

Open
sciurus opened this issue Nov 17, 2021 · 0 comments

Comments

@sciurus
Copy link

sciurus commented Nov 17, 2021

I have a self-hosted runner on an EC2 instance that has the necessary IAM permissions granted via its instance profile.

On this instance, I am able to successfully interact with CodeBuild via the AWS CLI and Node.js SDK.

However, attempting to use this action fails with the message "No credentials. Try adding @aws-actions/configure-aws-credentials earlier in your job to set up AWS credentials."

I think the assertion below is not correct. In some cases, credentials are available, they just have not been initialized yet.

assert(
codeBuild.config.credentials && cloudWatchLogs.config.credentials,
"No credentials. Try adding @aws-actions/configure-aws-credentials earlier in your job to set up AWS credentials."
);

The following test script can be used to demonstrate this.

const aws = require("aws-sdk");

const codeBuild = new aws.CodeBuild({
    customUserAgent: "aws-actions/aws-codebuild-run-build",
});

console.log("The credentials object before using the API: " + codeBuild.config.credentials);

codeBuild.listProjects(function (err, data) {
  if (err) console.log(err, err.stack); // an error occurred
  else console.log("The credentials object after using the API: " + codeBuild.config.credentials);   // successful response
});

If I run it on my EC2 instance, the output is

$ node test.js 
The credentials object before using the API: null
The credentials object after using the API: [object Object]

So you can see that it was null at first, which is why your assertion failed, but that the API call actually succeeded.

I think the assertion should be reworked somehow to be more robust, or you could just remove it and catch and report permissions failures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant