I do not understand why the awsKmsKeyArn field needs to be on the service object to apply to all functions instead of using the provider object. Anyone have an idea?
Got your point. The better way is to raise a feature/bug issue ticket to this open source repository directly.
service:
name: myService
awsKmsKeyArn: arn:aws:kms:us-east-1:XXXXXX:key/some-hash # Optional KMS key arn which will be used for encryption for all functions
thanks for the feedback
I dig the changes about this feature, and seems the developer has difficulty to move it to provider.
Add KMS key support by pmuens 路 Pull Request #3672 路 serverless/serverless 路 GitHub
Thanks for the feedback @candlerb
Yes, it's surprising that this is nested under service. We did this as an attempt to make the config more provider independent and prefix all the provider dependent configs with their respective provider name (in this case aws). But because of backwards compatibility we still have to support configs on the provider level. That's why they're mixed right now.
Thanks for pointing out the other issues and problems 馃憤. Could you open up new issues here in GitHub so that we can track them? Thanks in advance!
Add KMS key support by pmuens 路 Pull Request #3672 路 serverless/serverless 路 GitHub
@hassankhan thanks for the feedback
Does this support a awsKmsKeyArn on the provider rather than for each individual function?
We wanted to start with the most simple solution here, but yeah, adding it to the provider level isn't super complex and might provide better DX. 馃憤
and this:
Add KMS key support by pmuens 路 Pull Request #3672 路 serverless/serverless 路 GitHub
Thanks for the review @nalbion
Regarding your question why we've prefixed it with aws:
Does it have to be awsKmsKeyArn instead of kmsKeyArn? 馃槣
Yes, that's a good question! We're currently (re)-writing the code to be as provider independent as possible. Having kmsKeyArn as a config value isn't provider independent. Everything which only works with one provider will be prefixed with the provider name in the future to show the relation. Important to note here is that this only holds true for config such as function level config. We don't do this for events.
I just pushed an update so that service wide KMS key arn configurations are possible (function level KMS key arn configs will overwrite those). This should make the configuration less repetitive if a service wide KMS key is used.
/cc @eahefnawy @brianneisler