feat(lambda): grant function permissions to an AWS organization

[kaizencc]

Closes #19538, also fixes #20146. I combined them because they touch the same surface area and it would be too hairy to separate them out.

See lambda docs for this feature.

Introduces functionality to grant permissions to an organization in the following ways:

declare const  fn = new lambda.Function;

// grant to an organization
fn.grantInvoke(iam.OrganizationPrincipal('o-xxxxxxxxxx');

// grant to an account in an organization
fn.grantInvoke(iam.AccountPrincipal('123456789012').inOrganization('o-xxxxxxxxxx'));

---

All Submissions:

• Have you followed the guidelines in our Contributing guide?

Adding new Unconventional Dependencies:

• This PR adds new unconventional dependencies following the process described here

New Features

• Have you added the new feature to an integration test?
  • Did you use yarn integ to deploy the infrastructure and generate the snapshot (i.e. yarn integ without --dry-run)?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[kaizencc]

are these instanceof's okay? Reading the comment on line 551/561, "after v2, we can change these to instanceof" which makes me think that new additions can use instanceof directly.

[rix0rrr]

It's actually not true. That comment is a lie.

[kaizencc]

removed the "lie" then, and used duck-typing

[kaizencc]

I will update this integ test to use inOrganization if/when #20109 is merged

[rix0rrr]

Can we not do without this type test? Can we not parse the policyfragment conditions and detect the principal from there?

[rix0rrr]

Or better yet, doesn't validateCombinations return this value already?

[kaizencc]

You're right. It's redundant, but I had to fix a bug in isPrincipalWithConditions to make it happen.

[rix0rrr]

This feels nasty, and should not be necessary? OrganizationPrincipals fragment looks like this:

  public get policyFragment(): PrincipalPolicyFragment {
    return new PrincipalPolicyFragment(
      { AWS: ['*'] },
      { StringEquals: { 'aws:PrincipalOrgID': this.organizationId } },
    );
  }

So it should already fall properly into the cases below, where we parse the output of policyFragment and parse the AWS key out?

(Honestly -- that should be the only thing we do. The duck typing here above is 🤮)

[kaizencc]

i'm down to move it out, but the case below has the comment

// The principal cannot have conditions and must have a single { AWS: [arn] } entry.

OrganizationPrincipal has the condition StringEquals, so it fails. @rix0rrr since you were the one who introduced that comment, can you explain why the principal cannot have conditions? maybe we can loosen the logic to allow for something like OrganizationPrincipal to be parsed, but until then, the duck typing stays :).

[kaizencc]

    // Try a best-effort approach to support simple principals that are not any of the predefined
    // classes, but are simple enough that they will fit into the Permission model. Main target
    // here: imported Roles, Users, Groups.
    //
    // The principal cannot have conditions and must have a single { AWS: [arn] } entry.
    const json = principal.policyFragment.principalJson;
    if (Object.keys(principal.policyFragment.conditions).length === 0 && json.AWS) {
      if (typeof json.AWS === 'string') { return json.AWS; }
      if (Array.isArray(json.AWS) && json.AWS.length === 1 && typeof json.AWS[0] === 'string') {
        return json.AWS[0];
      }
    }

the parsing logic, for reference.

[rix0rrr]

In that case, I'd still prefer to see something like:

const stringEquals = matchSingleKey('StringEquals', principal.policyFragment.conditions));
if (stringEquals) {
  const orgId = matchSingleKey('aws:PrincipalOrgID', stringEquals);
  if (orgId) {
    return '*';
  }
}

Right?

What I'm trying to get at is that we look at the existing AWS principal and conditions, and parse and convert those to Lambda Permissions.

Instead of, what the code is historically doing, is looking at what classes you used and using "inside" knowledge of what those classes represent to generate the right output.

[kaizencc]

I've done this for org principal. I wanted to refactor the others to follow the same approach, but I couldn't get it to work. The approach works for org principal because we can identify the org principal from its policy fragment. That isn't the case for something like ArnPrincipal and AccountPrincipal, since both their policy fragments have just an arn value.

[rix0rrr]

You are right. But watch out! The return type of this function is a type assertion, which is now no longer true! You need to fix the return type and callsites as well.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: bbc7420
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[albertodiazdorado]

Hi! Upgrading from 2.29.1 to 2.30.0 breaks my project:

Error: PrincipalWithConditions had unsupported conditions for Lambda permission statement: [{"operator":"ArnEquals","key":"aws:SourceArn"}]. Supported operator/condition pairs: [{"operator":"ArnLike","key":"aws:SourceArn"},{"operator":"StringEquals","key":"aws:SourceAccount"},{"operator":"StringEquals","key":"aws:PrincipalOrgID"}]

Is there any super-easy fix that I am missing? Surprised to see my project break with a minor upgrade :(

[albertodiazdorado]

Well, I fixed it -- just had to read the error message carefully.

I replaced

    const servicePrincipal = new ServicePrincipal("events.amazonaws.com", {
      conditions: {
        ArnEquals: {
          "aws:SourceArn": myRule.ruleArn
        }
      }
    });

by

    const servicePrincipal = new ServicePrincipal("events.amazonaws.com", {
      conditions: {
        ArnLike: {
          "aws:SourceArn": myRule.ruleArn
        }
      }
    });

Just out of curiosity: you don't follow semantic versioning?