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

Change auth mechanism to support the standards. #263

Merged
merged 1 commit into from
Aug 28, 2019
Merged

Change auth mechanism to support the standards. #263

merged 1 commit into from
Aug 28, 2019

Conversation

n2aws
Copy link
Contributor

@n2aws n2aws commented Aug 6, 2017

This update changes the default auth mechanism to allow the SDK to use
whatever crdentials are available if the key and token aren't provided
in the config. This will allow ice to work in additional environments
such as Amazon ECS, while still allowing the original enviornments to
continue working as they had.

Assuming the credentials aren't provided in the config, they will be
found and used in the following order (direct cut/paste from the Java SDK
documentation):


AWS credentials provider chain that looks for credentials in this order:

  • Environment Variables - AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (RECOMMENDED since they are recognized by all the AWS SDKs and CLI except for .NET), or AWS_ACCESS_KEY and AWS_SECRET_KEY (only recognized by Java SDK)
  • Java System Properties - aws.accessKeyId and aws.secretKey
  • Credential profiles file at the default location (~/.aws/credentials) shared by all AWS SDKs and the AWS CLI
  • Credentials delivered through the Amazon EC2 container service if AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" environment variable is set and security manager has permission to access the variable,
  • Instance profile credentials delivered through the Amazon EC2 metadata service

This update changes the default auth mechanism to allow the SDK to use
whatever crdentials are available if the key and token aren't provided
in the config. This will allow ice to work in additional environments
such as Amazon ECS, while still allowing the original enviornments to
continue working as they had.

Assuming the credentials aren't provided in the config, they will be
found and used in the following order (direct cut/paste from the Java SDK
documentation):

AWS credentials provider chain that looks for credentials in this order:
 - Environment Variables - AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (RECOMMENDED since they are recognized by all the AWS SDKs and CLI except for .NET), or AWS_ACCESS_KEY and AWS_SECRET_KEY (only recognized by Java SDK)
 - Java System Properties - aws.accessKeyId and aws.secretKey
 - Credential profiles file at the default location (~/.aws/credentials) shared by all AWS SDKs and the AWS CLI
 - Credentials delivered through the Amazon EC2 container service if AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" environment variable is set and security manager has permission to access the variable,
 - Instance profile credentials delivered through the Amazon EC2 metadata service
@n2aws
Copy link
Contributor Author

n2aws commented Aug 22, 2017

I've seen a couple PR's about authentication, and I believe this one PR will address the biggest issues in #244 as well as #145 by moving to the standard AWS credentialling system used by the java SDK, instead of having several workarounds.

NitriKx added a commit that referenced this pull request Aug 29, 2017
@NitriKx NitriKx self-requested a review September 5, 2017 15:53
@NitriKx NitriKx self-assigned this Sep 5, 2017
@NitriKx NitriKx added this to the v1.1.3 milestone Sep 5, 2017
@cxmcc cxmcc mentioned this pull request Sep 6, 2017
@acmcelwee
Copy link
Contributor

FWIW, I've deployed this to our ECS cluster, and it's working like a champ. I'd love to see this merged so we can go back to building our container from the mainline releases.

@nfonrose
Copy link
Member

nfonrose commented Sep 14, 2017 via email

@acmcelwee
Copy link
Contributor

@nfonrose happy to help. Can you give me an idea of your baseline so I know what you need to test this out?

  • Are you familiar w/ ECS
  • Do you already have an ECS cluster running?

If the answer is yes to both of those, I might be able to pull together a test harness for you create a new ECS service running the Ice container, but if your baseline isn't quite there, I think it's a bit more work that I have time for to get a fully working service up for you to validate.

@nfonrose
Copy link
Member

Hi Adam, thanks for the help offer.

We're familiar with ECS but don't have an ECS cluster running as we don't use ECS to run the Ice instances for our SaaS service. But we can get one running fairly easily, so let's say I replied yes to both questions :-)

We don't really need a proper test harness. Just a "CloudFormation template" or "AWS CLI based script" that would deploy your version of Ice (that we have already merged into the ice integration branch) into a running ECS cluster. That way we can easily check that it's running fine.

@n2aws
Copy link
Contributor Author

n2aws commented Aug 27, 2019

Any updates for this? Is teevity still supporting this project?

@nfonrose nfonrose merged commit 608e096 into Teevity:master Aug 28, 2019
@nfonrose
Copy link
Member

nfonrose commented Aug 28, 2019 via email

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

Successfully merging this pull request may close these issues.

4 participants