[
https://issues.apache.org/jira/browse/NIFI-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089832#comment-15089832
]
James Wing commented on NIFI-786:
---------------------------------
The various AWS credential methods should not be thought of as simply different
ways to get to a set of API keys, but as different practices for credential
configuration management and deployment. For example,
* How will the dev team use credentials to develop and test on their own
machines?
* How can test/stage/production credentials be managed in the runtime
environments?
* How will cross-account access credentials for customer or partner systems be
obtained and controlled?
* How will credentials be rotated for long-running systems?
* How will credentials be managed across large fleets of servers?
AWS has put a great deal of thought into these problems, and their solutions
have evolved over time. One unfortunate result is the bewildering array of
credential options available now. But current AWS propaganda emphasizes IAM
Roles, EC2 instance profiles, and named profiles (from users'
~/.aws/credentials file) over directly providing API keys in application code
or config files.
* [A New and Standardized Way to Manage Credentials in the AWS
SDKs|https://blogs.aws.amazon.com/security/post/Tx3D6U6WSFGOK2H/A-New-and-Standardized-Way-to-Manage-Credentials-in-the-AWS-SDKs]
* [Providing AWS Credentials in the AWS SDK for
Java|http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/credentials.html]
* [Adhere to IAM Best Practices in 2016 (see #10 and
#11)|https://blogs.aws.amazon.com/security/post/Tx2OB7YGHMB7WCM/Adhere-to-IAM-Best-Practices-in-2016]
The following is a non-exhaustive list of AWS credential methods, and their
currently status in NiFi. I recommend NiFi eventually support all of these.
||Credential Method||NiFi Support||Inputs||Notes||
|[Anonymous|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/AnonymousAWSCredentials.html]|Y|(none)|Default
in NiFi. Not widely usable for most AWS services, except S3?|
|[Basic|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/BasicAWSCredentials.html]|Y|Access
Key ID, Secret Key|Lowest-common denominator, useful for troubleshooting, but
not recommended|
|[Properties
File|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/PropertiesCredentials.html]|Y|Path
to file with keys| |
|[Default|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/DefaultAWSCredentialsProviderChain.html]|N|(none)|The
["Default Credential Provider
Chain"|http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/credentials.html#id1]
is idiomatic across AWS tools and covers many configuration scenarios,
especially EC2 Instance Profile and the default user profile|
|[Named
Profile|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/profile/ProfileCredentialsProvider.html]|N|Profile
name|Picks a named option out of ~/.aws/credentials file, allowing for
multiple methods to be configured on the machine and used in different
processors|
|[Assumed
Role|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/STSAssumeRoleSessionCredentialsProvider.html]|N|Role
ARN, Session Name, ExternalID (opt.)|Two-stage credential, requires one of the
above before assuming role. Recommended for cross-account access, see
NIFI-1325|
To me, the absence of the Default Credential Chain is the most pressing for
NiFi. It would be my preference to have the Default Credentials used as the
unconfigured default for AWS processors rather than the Anonymous Credential,
as is currently the case. This might be a separate issue than a centralized
credential service, and maybe I should create a separate ticket. Does anyone
know if the Anonymous Credential is currently used out of an affirmative desire
to be anonymous or out of a need to return a sensible default matching the
interface? Changing this unconfigured behavior would be a theoretically
breaking change, but I'm skeptical about how useful Anonymous Credentials are
as-is.
> 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)
