Closed jerroldgao closed 10 months ago
@jerroldgao - Could you suggest a change for this and push a PR update?
@jerroldgao - Would you be able to suggest a PR?
hi @jerroldgao! I'll quote you and try adding some value here:
Also the link provided in article direct to AWS Go SDK 1, while the recommend authentication with v4 signature is using AWS Go SDK 2. The document might be misleading at the perspective of best practice
dapr AWS components use AWS Go SDK v1. Using v2 SDK is not mandatory and v1 has no declared EOL afaik. Regarding the The signature v4 ("SigV4") - it is used in both versions of AWS SDK so I don't think one SDK version is better than the other in terms of providing standard AWS API call in terms of security.
The reference in the doc to kiam and kube2iam should be rephrased as EKS already supports their functionality out of the box (providing oauth2 authentication on k8s using IAM credentials)
In addition, if you read through this article, you might find it is a little bit confusing to user. Attaching IAM role might be the alternative to hardcode in credential, but IAM role also provide provider chain, and SDK read from it from local environment. In addition, IAM is recommended way to hard code provider chain.
The above is correct, and we are introducing a better explanation to what the user actually needs to provide if using IAM policies and roles attached to its running Pod/Nodes, etc.
@jerroldgao - Would you be able to suggest a PR?
Sorry that I just look the back message here, I am living in Shanghai and it has been quite tough in past two months. Let me catch up on contributing guidance, and I think I can work on it since Shanghai is turning normal
dapr AWS components use AWS Go SDK v1. Using v2 SDK is not mandatory and v1 has no declared EOL afaik. Regarding the The signature v4 ("SigV4") - it is used in both versions of AWS SDK so I don't think one SDK version is better than the other in terms of providing standard AWS API call in terms of security.
The reference in the doc to kiam and kube2iam should be rephrased as EKS already supports their functionality out of the box (providing oauth2 authentication on k8s using IAM credentials)
Thanks for replying this! Though I agree there is no major functional improvement on SigV4(AWS claimed that it is safer, and I am not going to argue that), there are some hidden limitations on SigV1.
Eg. S3 has preassigned link and if you are using v1, that preassigned url is only last for 6 hours, while SigV4 can last to 7 days. It is a minor issue, but still probably not the best practice for user to setup their authentication. I made an assumption that most of Dapr users are setting up for new project, so it is better to setup the recommended authentication at beginning.
May I also know if there is a working branch for it? I can see if I can follow it up first and see what I can contribute it.
Describe the issue Hello, I am translating dapr doc into Chinese and find the sentence logic and term using are neither friendly to AWS master or new comer. URL of the docs https://docs.dapr.io/developing-applications/integrations/aws/authenticating-aws/
Expected content
The attributes here is the same as provider chain. Also the link provided in article direct to AWS Go SDK 1, while the recommend authentication with v4 signature is using AWS Go SDK 2. The document might be misleading at the perspective of best practice
Though I admit AWS v4 document is also not that reader friendly, the article of v4 signature explained the process and there is v2 SDK such as Java and Golang, normally it is supported by SDK natively.
In addition, if you read through this article, you might find it is a little bit confusing to user. Attaching IAM role might be the alternative to hardcode in credential, but IAM role also provide provider chain, and SDK read from it from local environment. In addition, IAM is recommended way to hard code provider chain. Screenshots
Additional context I think we should direct reader to know AWS authentication concept first and then tell them how to configure authentication