Add KMS permission(s) that may be optionally needed about aws-lambda-power-tuning HOT 11 OPEN

Hi @KaanErturk 👋 thanks for reaching out!

Could you please share more about your use case? Why did the Lambda Power Tuning function need the kms:CreateGrant permission to use a KMS key? Or was it required by the function you were power-tuning?

from aws-lambda-power-tuning.

@KaanErturk any updates? I'd like to address this, if you could share more details 😄

from aws-lambda-power-tuning.

Hi @alexcasalboni , kms:CreateGrant permission was required by the state machine task that invoked my Lambda function(s), for the KMS key they were using (to encrypt environment variables).

I think an ideal solution would be to allow attaching an additional IAM policy to the state machine tasks' IAM role(s) via configuration at the deployment stage.

from aws-lambda-power-tuning.

@KaanErturk thanks for the additional info!

I'm still struggling to understand the main reason/action for this issue though.

The required permission is for your own Lambda functions, right? (not for Lambda Power Tuning's functions)

What does Lambda Power Tuning have to do with the IAM policies of your Lambda function? Why would that kms:CreateGrant permission be required for Lambda Power Tuning's IAM roles too?

Is that a requirement for your AWS account(s)? Does the deployment of Lambda Power Tuning fail without that permission?

from aws-lambda-power-tuning.

The required permission is for your solution's IAM roles, NOT mine.

I deployed your solution without an issue. When I ran it, it failed. When I checked the CloudTrail logs I saw the error about the missing permission. I added it to your Lambda functions' IAM roles (all of them but IIRC it was needed by the first function) and then it worked, hence my suggestion about users (us, not you) being able to attach additional (custom) IAM policies to your solution, so you don't have to add a particular permission everytime someone has a similar issue.

from aws-lambda-power-tuning.

I see.

Indeed that would makes sense and add a lot of flexibility. Not sure if it's a best practice to implement IAM policies in the form of CloudFormation Parameters, as you probably want to include/validate/track those in proper IaC. The best (most secure) option for these use cases might still be to fork the repo and customize permissions in the YAML template.

And have you figured out why these permissions were required to run successfully? Is that required by your company's AWS account with something like AWS Config Rules?

from aws-lambda-power-tuning.

I was thinking more of just attaching an IAM policy that I created as part of my infrastructure. You don't need to support creating that additional IAM policy, just be able to attach it.

I don't know why that permission was required by your Lambda functions. But it has nothing to do with AWS account setup or Config rules, etc. I just keep my KMS and IAM policies quite tight.

Have you tested your solution with Lambda functions that use KMS keys with tight policies? I shouldn't be the only one to use those, right? 🙂

from aws-lambda-power-tuning.

I admit I haven't tested Lambda Power Tuning with functions that use KMS keys, but so far I had assumed that whatever IAM policy the target function is using, it shouldn't affect who can invoke it (as long as the Lambda Power Tuning functions have the right permissions such as lambda:InvokeFunction, lambda:GetFunctionConfiguration, lambda:GetAlias, etc.).

Could you please provide a simple CloudFormation template with your function definition (and IAM/KMS policies) so I can deploy it and run a few tests?

from aws-lambda-power-tuning.