Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid principal type for Lambda permission statement: ArnPrincipal. Supported: AccountPrincipal, ServicePrincipal #3264

Closed
IainCole opened this issue Jul 9, 2019 · 5 comments · Fixed by #3501
Assignees
Labels
@aws-cdk/aws-iam Related to AWS Identity and Access Management @aws-cdk/aws-lambda Related to AWS Lambda

Comments

@IainCole
Copy link
Contributor

IainCole commented Jul 9, 2019

I'm trying to allow a lambda function in another account to be able to invoke my CDK generated lambda function. This works through the CLI like so:

aws lambda add-permission --function-name=myFunction --statement-id=ABoldStatement --action=lambda:InvokeFunction --principal=arn:aws:iam::<account_id>:role/a_lambda_execution_role

But CDK doesn't seem to allow me to add an ArnPrincipal doing something like this:

myFunction.grantInvoke(new iam.ArnPrincipal(props.myARN))

With the error Invalid principal type for Lambda permission statement: ArnPrincipal. Supported: AccountPrincipal, ServicePrincipal

Seems to be around here https://github.com/awslabs/aws-cdk/blob/4a0272db5eb9aae5f440bb0813fdbad6514b60c3/packages/%40aws-cdk/aws-lambda/lib/function-base.ts#L278

I can see about adding this if we think it's correct to add.

@IainCole IainCole added the needs-triage This issue or PR still needs to be triaged. label Jul 9, 2019
@IainCole
Copy link
Contributor Author

IainCole commented Jul 9, 2019

FWIW I changed the code locally and it seemed to do the right thing =)

@NGL321
Copy link
Contributor

NGL321 commented Jul 10, 2019

Hi @IainCole,
If you resolved this issue yourself, please go ahead and close out the issue or let us know so we can do the same!
Otherwise I'm happy to look into the problem 😸

@NGL321 NGL321 added closing-soon This issue will automatically close in 4 days unless further comments are made. @aws-cdk/aws-iam Related to AWS Identity and Access Management @aws-cdk/aws-lambda Related to AWS Lambda response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. and removed needs-triage This issue or PR still needs to be triaged. labels Jul 10, 2019
@IainCole
Copy link
Contributor Author

I resolved it by editing the CDK source code, I can provide a PR with the change I made if you like.

@IainCole
Copy link
Contributor Author

I made an example here: IainCole@c2cc010 I'm not sure if there should be more validation around which ARNs are valid for grantInvoke because I think only some are (like IAM roles and API gateway stages)

@NGL321
Copy link
Contributor

NGL321 commented Aug 1, 2019

Hey @IainCole!

Sorry it's taken me so long to get back to you on this. That looks like a great PR opportunity.
Go ahead and submit one and tag me in it.

I will leave this issue open so that it can be resolved by the PR

@NGL321 NGL321 self-assigned this Aug 1, 2019
@NGL321 NGL321 removed closing-soon This issue will automatically close in 4 days unless further comments are made. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. labels Aug 1, 2019
eladb pushed a commit that referenced this issue Aug 5, 2019
Fixes #3264 

I'm trying to allow a lambda function in another account to be able to invoke my CDK generated lambda function. This works through the CLI like so:

    aws lambda add-permission --function-name=myFunction --statement-id=ABoldStatement --action=lambda:InvokeFunction --principal=arn:aws:iam::{account_id}:role/a_lambda_execution_role

But CDK doesn't seem to allow me to add an ArnPrincipal doing something like this:

    myFunction.grantInvoke(new iam.ArnPrincipal(props.myARN))

With the error:

    Invalid principal type for Lambda permission statement: ArnPrincipal. Supported: AccountPrincipal, ServicePrincipal

This PR allows ArnPrincipal to be passed to lambda.grantInvoke.

There might be some additional validation required on the exact ARN as I believe only some ARNs are supported by lambda add-permission
eladb pushed a commit that referenced this issue Aug 6, 2019
Fixes #3264 

I'm trying to allow a lambda function in another account to be able to invoke my CDK generated lambda function. This works through the CLI like so:

    aws lambda add-permission --function-name=myFunction --statement-id=ABoldStatement --action=lambda:InvokeFunction --principal=arn:aws:iam::{account_id}:role/a_lambda_execution_role

But CDK doesn't seem to allow me to add an ArnPrincipal doing something like this:

    myFunction.grantInvoke(new iam.ArnPrincipal(props.myARN))

With the error:

    Invalid principal type for Lambda permission statement: ArnPrincipal. Supported: AccountPrincipal, ServicePrincipal

This PR allows ArnPrincipal to be passed to lambda.grantInvoke.

There might be some additional validation required on the exact ARN as I believe only some ARNs are supported by lambda add-permission
mergify bot pushed a commit that referenced this issue Aug 7, 2019
* chore: update package-lock.json

* feat(eks): define kubernetes resources

This change allows defining arbitrary Kubernetes resources within an EKS cluster.

* nice!

* update readme

* Update README.md

* feat(events): ability to add cross-account targets (#3323)

This adds the capability of adding a target to an event rule
that belongs to a different account than the rule itself.
Required for things like cross-account CodePipelines with source actions triggered by events.

* chore(ci): add mergify config file (#3502)

* chore: update jsii to 0.14.3 (#3513)

* fix(iam): correctly limit the default PolicyName to 128 characters (#3487)

Our logic for trimming the length of the default IAM policy name was not working,
as it wasn't updated when logicalId became a Token rather than a literate string,
and so it was never actually triggered
(it just checked that the display name of the Token was less than 128 characters,
which it always is).
The fix is to resolve the logical ID Token before applying the trimming logic.

Fixes #3402

* v1.3.0 (#3516)

See CHANGELOG

* fix: typo in restapi.ts (#3530)

* feat(ecs): container dependencies (#3032)

Add new addContainerDependencies method to allow for container dependencies
Fixes #2490

* feat(s3-deployment): CloudFront invalidation (#3213)

see #3106

* docs(core): findChild gets direct child only (#3512)

* doc(iam): update references to addManagedPolicy (#3511)

* fix(sqs): do not emit grants to the AWS-managed encryption key (#3169)

Grants on the `alias/aws/sqs` KMS key alias are not necessary since the
key will implicitly allow for it's intended usage to be fulfilled (as
opposed to how you have to manage grants yourself when using a
user-managed key instead).

This removes the statement that was generated using an invalid resource
entry.

Fixes #2794

* fix(lambda): allow ArnPrincipal in grantInvoke (#3501)

Fixes #3264 

I'm trying to allow a lambda function in another account to be able to invoke my CDK generated lambda function. This works through the CLI like so:

    aws lambda add-permission --function-name=myFunction --statement-id=ABoldStatement --action=lambda:InvokeFunction --principal=arn:aws:iam::{account_id}:role/a_lambda_execution_role

But CDK doesn't seem to allow me to add an ArnPrincipal doing something like this:

    myFunction.grantInvoke(new iam.ArnPrincipal(props.myARN))

With the error:

    Invalid principal type for Lambda permission statement: ArnPrincipal. Supported: AccountPrincipal, ServicePrincipal

This PR allows ArnPrincipal to be passed to lambda.grantInvoke.

There might be some additional validation required on the exact ARN as I believe only some ARNs are supported by lambda add-permission

* chore(contrib): remove API stabilization disclaimer

* fix(ssm): add GetParameters action to grantRead() (#3546)

* misc

* rename `KubernetesManifest` to `KubernetesResource` and `addResource`
* move AWS Auth APIs to `cluster.awsAuth` and expose `AwsAuth`
* remove the yaml library (we can just use a JSON stream)
* add support for adding accounts to aws-auth
* fix cluster deletion bug
* move kubctl app info to constants

* addManifest => addResource

* update test expectations

* add unit test for customresrouce.ref

* fix sample link
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-iam Related to AWS Identity and Access Management @aws-cdk/aws-lambda Related to AWS Lambda
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants