[
https://issues.apache.org/jira/browse/NIFI-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14949828#comment-14949828
]
Michael Kobit edited comment on NIFI-786 at 10/9/15 3:21 AM:
-------------------------------------------------------------
[~markap14] Hey Mark, my initial idea was that the {{ControllerService}} would
return an
[{{AWSCredentialsProvider}}|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/AWSCredentialsProvider.html]
not an
[{{AWSCredentials}}|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/AWSCredentials.html].
The {{*Provider}} can be used for supplying credentials that don't change, the
static access and secret key use case now, but also allows for complicated
implementations, like the ones that integrate with key management systems (like
via [STS|http://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html]). I
am fairly certain it is supported by all of the SDK vended
{{Amazon*ServiceClient}}
For the use case of typing them in the UI, it would be supported by the, what I
called above, {{StaticAwsCredentialsProviderService}} {{ControllerService}}.
Users would type in the access/secret keys like they can do now, although they
would have to set it up at the controller service level rather than at a
processor level. This way it could also be reused across multiple AWS
processors.
For the properties file use case, it would be supported by the, what I called
above, {{PropertiesFileAwsCredentialsProviderService}} {{ControllerService}}.
This implementation I would see using the AWS SDK
[PropertiesFileCredentialsProvider|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/PropertiesFileCredentialsProvider.html].
It covers the file based use case, but it also (currently) allows for
credential rotation in the file since it gets loaded every time.
One of the main use cases I was thinking of is when running on AWS and you are
["Using IAM Roles to Grant Access to AWS Resources on Amazon
EC2"|http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-roles.html].
Basically distributing the credentials to the EC2 instances themselves rather
than managing them in your application. The keys are temporary and AWS
automatically rotates them, so using the AWS Java SDK
{{AWSCredentialsProvider}} implementation is preferred.
A couple other possible use cases that could be supported fairly easily:
1. environment variables
2. Java system properties
And then there is the option of allowing consumers to define their own
{{ControllerService}} for retrieving credentials.
was (Author: mkobit):
[~markap14] Hey Mark, my initial idea was that the ControllerService}} would
return an
[{{AWSCredentialsProvider}}|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/AWSCredentialsProvider.html]
not an
[|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/AWSCredentials.html].
The {{*Provider}} can be used for supplying credentials that don't change, the
static access and secret key use case now, but also allows for complicated
implementations, like the ones that integrate with key management systems (like
via [STS|http://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html]). I
am fairly certain it is supported by all of the SDK vended
{{Amazon*ServiceClient}}
For the use case of typing them in the UI, it would be supported by the, what I
called above, {{StaticAwsCredentialsProviderService}} {{ControllerService}}.
Users would type in the access/secret keys like they can do now, although they
would have to set it up at the controller service level rather than at a
processor level. This way it could also be reused across multiple AWS
processors.
For the properties file use case, it would be supported by the, what I called
above, {{PropertiesFileAwsCredentialsProviderService}} {{ControllerService}}.
This implementation I would see using the AWS SDK
[PropertiesFileCredentialsProvider|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/PropertiesFileCredentialsProvider.html].
It covers the file based use case, but it also (currently) allows for
credential rotation in the file since it gets loaded every time.
One of the main use cases I was thinking of is when running on AWS and you are
["Using IAM Roles to Grant Access to AWS Resources on Amazon
EC2"|http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-roles.html].
Basically distributing the credentials to the EC2 instances themselves rather
than managing them in your application. The keys are temporary and AWS
automatically rotates them, so using the AWS Java SDK
{{AWSCredentialsProvider}} implementation is preferred.
A couple other possible use cases that could be supported fairly easily:
1. environment variables
2. Java system properties
And then there is the option of allowing consumers to define their own
{{ControllerService}} for retrieving credentials.
> Add other supporting options for configuring credentials for AWS processors
> ---------------------------------------------------------------------------
>
> Key: NIFI-786
> URL: https://issues.apache.org/jira/browse/NIFI-786
> Project: Apache NiFi
> Issue Type: Improvement
> Affects Versions: 0.3.0
> Reporter: Michael Kobit
> Priority: Minor
>
> I was looking at https://issues.apache.org/jira/browse/NIFI-770 and looked at
> how the AWS processors credentials are currently configured. As a NFM you
> have a few options with the properties right now:
> 1) set basic, static credentials
> 2) set a credentials properties filepath
> 3) set neither, use anonymous credentials
> I think it would be better if each AWS could rely on a ControllerService that
> returns `AWSCredentialsProvider` (instead of `AWSCredentials`) that gives
> all of the possible implementations that could be used, rather than relying
> on a static credentials. *Provider implementations can be refreshed and can
> also other more complicated implementations, but already have built in
> support for the Static and Properties file that are provided by NiFi today.
> My thinking is that the controller service would be something like
> public interface AwsCredentialsProviderService extends ControllerService {
> AWSCredentialsProvider getCredentialsProvider();
> }
> and you could have `StaticAwsCredentialsProviderService`,
> `PropertiesFileAwsCredentialsProviderService`, and
> `AnonymousAwsCredentialsProviderService` to provide the functionality that is
> supported right now. Additional credential providers could be added later, as
> there a bunch more AWS provided versions that I think could fit in well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
