feat(iam): immutable IAM roles #4501

skinny85 · 2019-10-14T23:40:32Z

This adds an IRole implementation that ignores all mutating operations.
Useful when you want to turn off CDK's automatic permissions management,
and have full control over a role's policy
(and/or if the CDK generated policy exceeds the size limit).
To accommodate this new behavior, add a new method to IIdentity:
addPolicy, which is meant to replace attachInlinePolicy,
which can leave Policy resources unattached, resulting in an invalid CloudFormation template.

Fixes #2985
Fixes #4465

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

mergify · 2019-10-14T23:41:09Z

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

PR title type(scope): text
- type: fix, feat, refactor go into CHANGELOG, chore is hidden
- scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
- text: use all lower-case, do not end with a period, do not include issue refs
PR Description
- Rationale: describe rationale of change and approach taken
- Issues: indicate issues fixed via: fixes #xxx or closes #xxx
- Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
Testing
- Unit test added. Prefer to add a new test rather than modify existing tests
- CLI or init templates change? Re-run/add CLI integration tests
Documentation
- README: update module README to describe new features
- API docs: public APIs must be documented. Copy from official AWS docs when possible
- Design: for significant features, follow design process

skinny85 · 2019-10-14T23:41:50Z

@rix0rrr this contains a proposal of adding a new method to IIdentity, and an example of using it inside CodeBuild's Project class here. Let me know what you think of this approach!

aws-cdk-automation · 2019-10-15T00:13:07Z

AWS CodeBuild CI Report

Result: SUCCEEDED
Build Logs (available for 30 days)

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

rix0rrr · 2019-10-16T09:41:19Z

packages/@aws-cdk/aws-codebuild/lib/project.ts

@@ -901,8 +901,7 @@ export class Project extends ProjectBase {
      },
    }));

-    const policy = new iam.Policy(this, 'PolicyDocument', {
-      policyName: 'CodeBuildEC2Policy',
+    const policy = this.role.createAndAttachPolicy('CodeBuildVpcPolicy', {


The fact that this can return nothing is a bit of a gotcha and feels like an unnatural API.

Can it not return a special kind of Policy object that doesn't render to CFN, or something?

Maybe the change should be that unattached Policy objects just don't render? This new method feels unnatural.

Why? Why is returning something optionally "unnatural"...?

Returning a magical Policy that won't render if it's unattached seems a lot more unnatural to me (we don't have a single resource in the library that behaves that way - doesn't render under some conditions), and also won't work in this case - we are making the Project depend on the Policy, so we can't not render it (the resulting template would be invalid).

Why? Why is returning something optionally "unnatural"...?

How is it to be expected that a function that is called createThing doesn't actually create and return a thing? What I don't like about this is:

Consumers have to write additional ifs. I will fight against any design that requires my consumers to add an if to their code.

We could only conceivably have typed this function this way once we have the requirement that there may be a class which doesn't do the thing. If we had made this function BEFORE we had the requirement of the no-op class, the API would have been locked in to the normal API (which always returns a thing) and then we wouldn't have been able to add this in this way. That leads me to think we are confusing layers of functionality.

we don't have a single resource in the library that behaves that way - doesn't render under some conditions

We do have objects that render differently under certain conditions (references turn into { Ref: xxx } or { Fn::ImportValue: Yyy } under certain conditions) so that is not without precedent. And in fact, we also have policy objects that automatically get added to the document if they're non-empty (see BucketPolicy, QueuePolicy, TopicPolicy).

Automatic adding on non-empty is roughly what I'm asking for here as well. The difference being that in the existing case, bucket.addToResourcePolicy() adds the AWS::IAM::Policy resource to the template, and in this case it would be policy.addToPolicy() that adds the AWS::IAM::Policy to the template.

Yes, the letter of the code will be different (because the class structure is slightly different), but I would argue it's in the same spirit.

And in any case, CDK is intended to make it easier to work with CloudFormation templates, not push the same problems and need for case analysis down to the user if we can deal with them.

we are making the Project depend on the Policy, so we can't not render it

Obviously we would have to not render the dependency in the case we're not rendering the resource. Yes, I understand it is more work, but it's not like that is impossible to do.

Consumers have to write additional ifs. I will fight against any design that requires my consumers to add an if to their code.

That's a noble point, only slightly undercut by the fact that we're adding a method to an interface with an existing method addToPolicy(statement: PolicyStatement): boolean...

Obviously we would have to not render the dependency in the case we're not rendering the resource. Yes, I understand it is more work, but it's not like that is impossible to do.

How? CfnResource.addDependsOn(resource) adds resource to a dependsOn Set field of CfnResource. How would you not render that?

And other cases - what if somebody does CfnOutput(this, 'Output', { value: policy.ref })? How could we possibly not renderpolicy in that case?

So probably this is a bad idea for CfnPolicy, but it could be true for Policy.

As for the second question, we could render it as { Ref: AWS::NoValue }. Not saying it's the best answer but it is an answer. Another thing we could do is reify the policy when someone refers to it. There is precedent for something like this btw, see iam.LazyRole.

As for addDependsOn()... that is an issue. We would really have to use addDependency, which has a mechanism (in IDependable) to control what gets depended on when you take a dependency on a thing.

I just spent basically the entire day implementing LazyPolicy (which I believe is basically what you asked). And it was horrible. Feel free to judge yourself (I've updated the PR with what I came up with).

We turned a clean, simple API into a Frankenstein monster full of hacks, throwing exceptions, and weird edge cases. I don't even know how to write the docs for this new method, it's so convoluted what it does now. And I'm still not able to actually make it work - the build fails on the codebuild package.

I really urge you to reconsider. I think we're going down the wrong path here.

rix0rrr · 2019-10-16T09:44:19Z

packages/@aws-cdk/aws-iam/lib/immutable-role.ts

+  }
+
+  public addToPolicy(_statement: PolicyStatement): boolean {
+    return false;


I think this might need to return true. I'm sorry :(.

I don't understand this comment. Can you elaborate?

/** * Add to the policy of this principal. * * @returns true if the statement was added, false if the principal in * question does not have a policy document to add the statement to. */ addToPolicy(statement: PolicyStatement): boolean;

I know that the statement wasn't really added, but false means that a policy statement could NEVER be added and one should be added to the resource instead.

In this case I guess it's a toss-up between "the user has already prepared all statements so don't do anything" and "this role is immutable so add to the resource instead."

I would say we either make it configurable between those 2, or default to the do-less option (with an option to make it configurable later). Right now, the do-less default is returning "true" (pretend everything worked fine attaching to the principal).

Shouldn't this be true here as well then...? (for roles imported with { mutable: false })

aws-cdk/packages/@aws-cdk/aws-iam/lib/role.ts

Lines 220 to 228 in ddb05f9

class ImmutableImport extends Import {

public addToPolicy(_statement: PolicyStatement): boolean {

return false;

}

public attachInlinePolicy(_policy: Policy): void {

// do nothing

}

}

Yes it should.

eladb

Please update the PR description to include the motivation for the change

eladb · 2019-10-16T09:51:11Z

packages/@aws-cdk/aws-codebuild/lib/project.ts

+      // otherwise, creating the Project fails,
+      // as it requires these permissions to be already attached to the Project's Role
+      const cfnPolicy = policy.node.defaultChild as CfnResource;
+      project.addDependsOn(cfnPolicy);


wouldn't it work to add the dependency on the policy object? I believe it should work.

project.addDependsOn(policy) doesn't compile (Policy is not a CfnResource)

this.node.addDependency(policy) adds way too much dependencies, including a circular one between policy and itself

What about this.node.addDependency(cfnPolicy)?

What about this.node.addDependency(cfnPolicy)?

Nope. Same as this.node.addDependency(policy) - a million dependencies, including a cyclical one.

eladb · 2019-10-16T09:52:20Z

packages/@aws-cdk/aws-iam/lib/identity-base.ts

+   *   It will be created in the scope of this principal (if it's mutable)
+   * @param props the construction properties of the new policy
+   */
+  createAndAttachPolicy(id: string, props?: PolicyProps): Policy | undefined;


This name is weird... "xAndY" is usually a sign of a bad name. Maybe just addPolicy? Semantically it means the same thing: role.addPolicy('foo', { xxx })

I was also thinking createAttachedPolicy might be a better name. What do you think?

For now, changed to addPolicy.

I'm also worried that addPolicy looks too similar to addToPolicy (which is a method present on the superinterface of IIdentity, IPrincipal).

packages/@aws-cdk/aws-iam/lib/immutable-role.ts

packages/@aws-cdk/aws-iam/lib/identity-base.ts

skinny85 · 2019-10-18T00:39:16Z

Changed the name of the new method to addPolicy and rebased.

aws-cdk-automation · 2019-10-18T01:26:27Z

AWS CodeBuild CI Report

Result: SUCCEEDED
Build Logs (available for 30 days)

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

skinny85 · 2019-10-21T22:18:08Z

Changed the name of the new method to addPolicy and rebased.

This time, actually changed it.

aws-cdk-automation · 2019-10-21T22:55:23Z

AWS CodeBuild CI Report

Result: SUCCEEDED
Build Logs (available for 30 days)

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

This adds an IRole implementation that ignores all mutating operations. To accommodate this new behavior, add a new method to IIdentity: createAndAttachPolicy, which is meant to replace attachInlinePolicy, which can leave Policy resources unattached, which is illegal in CloudFormation. Fixes aws#2985 Fixes aws#4465

aws-cdk-automation · 2019-10-23T03:27:54Z

AWS CodeBuild CI Report

Result: FAILED
Build Logs (available for 30 days)

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

rix0rrr · 2019-10-23T09:09:29Z

packages/@aws-cdk/aws-iam/lib/identity-base.ts

-   * This is the same as calling `policy.addToXxx(principal)`.
-   * @param policy The policy resource to attach to this principal [disable-awslint:ref-via-interface]
+   * Creates and attaches a Policy to this principal, if it is mutable.
+   * If this principal is immutable, does nothing, and returns undefined.


This docstring can't be correct anymore.

Yes. I'm actually struggling to write these docs, like I said here: #4501 (comment)

rix0rrr · 2019-10-23T09:11:48Z

packages/@aws-cdk/aws-iam/lib/lazy-policy.ts

+import { IRole } from './role';
+import { IUser } from './user';
+
+export class LazyPolicy extends Resource implements IPolicy {


Might need a docstring explaining what it does.

Does it work?

It does not currently, because of the magical overrides of ref and logicalId of the custom L1 here: https://github.com/aws/aws-cdk/pull/4501/files?file-filters%5B%5D=.ts#diff-f60a11b2b65df07bd241981fe0a626d7R37-R55

skinny85 · 2019-10-25T00:11:08Z

Hey @rix0rrr,

like I said before, I believe we're heading down the wrong path here. Even putting aside the fact that I can't get the code working with the hacky overrides needed for the L1 in LazyRole, I think the code that I had to write here, to make the vision of addPolicy(): IPolicy a reality, is bad. It's ugly, fragile, and I don't even know what exactly to write in the documentation of addPolicy(), it became so complicated.

Is there any way I can convince you to back out from this direction? I strongly feel this is the wrong thing to do.

rix0rrr · 2019-10-28T10:44:05Z

I implemented LazyPolicy by doing a deleteNode instead if it turned out to be empty. This probably also has nasty side effects somewhere, but so far seems to work? (haven't finished the build yet because it keeps failing for unrelated reasons).

If this approach does turn out to work, I'm still not sure this shouldn't be the default behavior of Policy (maybe using a flag, mustCreate: true|false or something?)

aws-cdk-automation · 2019-10-28T11:27:53Z

AWS CodeBuild CI Report

Result: SUCCEEDED
Build Logs (available for 30 days)

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

The DynamoDB global table construct was incorrectly declaring its dependencies. That resulted in resources in the coordinator stack depending on the global tables, which cannot work, as those are from different stacks. Changed the logic to declare dependencies between the stacks explicitly. Fixes aws#4501

skinny85

Few things:

I don't believe this does what we need in CodeBuild's Project class.
If we're going down the LazyPolicy route, maybe adding addToPolicy doesn't make much sense, and we should instead have clients of attachInlinePolicy create a LazyPolicy, and pass it there?

skinny85 · 2019-10-30T00:25:22Z

packages/@aws-cdk/aws-iam/test/lazy-policy.test.ts

+      }
+    }
+  });
+});


Can we have a test that shows the dependency is there if the policy was attached to anything?

skinny85 · 2019-10-30T00:31:58Z

packages/@aws-cdk/aws-codebuild/lib/project.ts

    // otherwise, creating the Project fails,
    // as it requires these permissions to be already attached to the Project's Role
-    const cfnPolicy = policy.node.findChild('Resource') as CfnResource;
+    const cfnPolicy = policy.node.defaultChild as CfnResource;


Does this work in the current version? From what I can tell, LazyPolicy extends Policy, and so this will leave a dependency in the template to a resource that will be later removed, if I'm correct.

rix0rrr · 2019-10-30T12:34:42Z

Please stop overwriting previous commits with git push -f.

I'm trying to find old comments back to see what your problems with addDependency were (why you needed to use addDependsOn) and I can't find it back anymore because for whatever reason GitHub has eaten the comment.

rix0rrr · 2019-10-30T13:23:38Z

I can't retrieve why addDependency wasn't good enough, but I switched the code back to it and it seems to work.... ?

2. If we're going down the LazyPolicy route, maybe adding addToPolicy doesn't make much sense, and we should instead have clients of attachInlinePolicy create a LazyPolicy, and pass it there?

Not exactly sure what you mean here, but if it's up to me we roll Policy and LazyPolicy into one and the distinction disappears.

aws-cdk-automation · 2019-10-30T13:43:57Z

AWS CodeBuild CI Report

Result: FAILED
Build Logs (available for 30 days)

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

aws-cdk-automation · 2019-10-30T13:49:08Z

AWS CodeBuild CI Report

Result: FAILED
Build Logs (available for 30 days)

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

aws-cdk-automation · 2019-10-30T14:05:58Z

AWS CodeBuild CI Report

Result: FAILED
Build Logs (available for 30 days)

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

skinny85 · 2019-10-30T16:43:01Z

Please stop overwriting previous commits with git push -f.

I'm trying to find old comments back to see what your problems with addDependency were (why you needed to use addDependsOn) and I can't find it back anymore because for whatever reason GitHub has eaten the comment.

I doubt it has to do anything with git push -f (a lot of comments from the first revision are still there...). I think it's because you changed the code in that part relative to the first revision, and GitHub removed those comments as out-of-date.

I can't retrieve why addDependency wasn't good enough, but I switched the code back to it and it seems to work.... ?

The issue was I was doing this.node.addDependency(policy), instead of project.node.addDependency(policy) (project is the L1) - the latter does indeed work.

skinny85 · 2019-10-30T16:50:32Z

If we're going down the LazyPolicy route, maybe adding addToPolicy doesn't make much sense, and we should instead have clients of attachInlinePolicy create a LazyPolicy, and pass it there?

Not exactly sure what you mean here, but if it's up to me we roll Policy and LazyPolicy into one and the distinction disappears.

I'm saying that:

We should export LazyPolicy from the IAM package (right now it's private to it).
We should remove the addPolicy method that was added in this PR.
In CodeBuild's Project, we should use LazyPolicy and attatchInlinePolicy instead of addToPolicy.

If you want to roll the capabilities of LazyPolicy into Policy itself, that's fine by me; in that case, substitute "LazyPolicy" with "Policy with mustCreate: false" in the above description.

Is this clearer now?

rix0rrr · 2019-10-31T09:00:36Z

If you want to roll the capabilities of LazyPolicy into Policy itself, that's fine by me; in that case, substitute "LazyPolicy" with "Policy with mustCreate: false" in the above description.

Yep, although I would have mustCreate: false by default.

I am fine with removing addPolicy() (though it could still be useful in the same way we have addListener() etc)

Who is going to finish this PR, you or me? I have a feeling our roles got reversed over the last few commits :)

I think it's because you changed the code in that part relative to the first revision, and GitHub removed those comments as out-of-date.

Yes but I've also seen it show old comments as "out-of-date". My current theory is that because the commit the comments are linked to is gone, it's not showing them anymore.

skinny85 · 2019-10-31T16:13:58Z

Yep, although I would have mustCreate: false by default.

I think that's fine. It's not strictly backwards-compatible, but I think the old behavior was purely an irritation, and didn't add much value.

Who is going to finish this PR, you or me? I have a feeling our roles got reversed over the last few commits :)

Go for it. I think that's fine that we switched roles, that's what collaboration is all about :).

I think you can also roll back all of the changes I did to IPolicy, and method signatures that I've changed from Policy to IPolicy - it made sense when LazyPolicy was another implementation of IPolicy, but since LazyPolicy will now be folded into Policy, they are not needed.

mergify · 2019-12-16T12:34:25Z

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

PR title type(scope): text
- type: fix, feat, refactor go into CHANGELOG, chore is hidden
- scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
- text: use all lower-case, do not end with a period, do not include issue refs
PR Description
- Rationale: describe rationale of change and approach taken
- Issues: indicate issues fixed via: fixes #xxx or closes #xxx
- Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
Testing
- Unit test added. Prefer to add a new test rather than modify existing tests
- CLI or init templates change? Re-run/add CLI integration tests
Documentation
- README: update module README to describe new features
- API docs: public APIs must be documented. Copy from official AWS docs when possible
- Design: for significant features, follow design process

mergify · 2019-12-16T13:01:30Z

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

PR title type(scope): text
- type: fix, feat, refactor go into CHANGELOG, chore is hidden
- scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
- text: use all lower-case, do not end with a period, do not include issue refs
PR Description
- Rationale: describe rationale of change and approach taken
- Issues: indicate issues fixed via: fixes #xxx or closes #xxx
- Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
Testing
- Unit test added. Prefer to add a new test rather than modify existing tests
- CLI or init templates change? Re-run/add CLI integration tests
Documentation
- README: update module README to describe new features
- API docs: public APIs must be documented. Copy from official AWS docs when possible
- Design: for significant features, follow design process

mergify · 2019-12-16T13:53:37Z

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

PR title type(scope): text
- type: fix, feat, refactor go into CHANGELOG, chore is hidden
- scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
- text: use all lower-case, do not end with a period, do not include issue refs
PR Description
- Rationale: describe rationale of change and approach taken
- Issues: indicate issues fixed via: fixes #xxx or closes #xxx
- Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
Testing
- Unit test added. Prefer to add a new test rather than modify existing tests
- CLI or init templates change? Re-run/add CLI integration tests
Documentation
- README: update module README to describe new features
- API docs: public APIs must be documented. Copy from official AWS docs when possible
- Design: for significant features, follow design process

mergify · 2019-12-16T14:39:24Z

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

PR title type(scope): text
- type: fix, feat, refactor go into CHANGELOG, chore is hidden
- scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
- text: use all lower-case, do not end with a period, do not include issue refs
PR Description
- Rationale: describe rationale of change and approach taken
- Issues: indicate issues fixed via: fixes #xxx or closes #xxx
- Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
Testing
- Unit test added. Prefer to add a new test rather than modify existing tests
- CLI or init templates change? Re-run/add CLI integration tests
Documentation
- README: update module README to describe new features
- API docs: public APIs must be documented. Copy from official AWS docs when possible
- Design: for significant features, follow design process

mergify · 2019-12-16T14:53:07Z

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

PR title type(scope): text
- type: fix, feat, refactor go into CHANGELOG, chore is hidden
- scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
- text: use all lower-case, do not end with a period, do not include issue refs
PR Description
- Rationale: describe rationale of change and approach taken
- Issues: indicate issues fixed via: fixes #xxx or closes #xxx
- Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
Testing
- Unit test added. Prefer to add a new test rather than modify existing tests
- CLI or init templates change? Re-run/add CLI integration tests
Documentation
- README: update module README to describe new features
- API docs: public APIs must be documented. Copy from official AWS docs when possible
- Design: for significant features, follow design process

mergify · 2019-12-16T15:18:23Z

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

PR title type(scope): text
- type: fix, feat, refactor go into CHANGELOG, chore is hidden
- scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
- text: use all lower-case, do not end with a period, do not include issue refs
PR Description
- Rationale: describe rationale of change and approach taken
- Issues: indicate issues fixed via: fixes #xxx or closes #xxx
- Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
Testing
- Unit test added. Prefer to add a new test rather than modify existing tests
- CLI or init templates change? Re-run/add CLI integration tests
Documentation
- README: update module README to describe new features
- API docs: public APIs must be documented. Copy from official AWS docs when possible
- Design: for significant features, follow design process

rix0rrr · 2019-12-27T15:04:07Z

Subsumed by new PR.

Add a new method to `Role` called `withoutPolicyUpdates()`, which returns a wrapper object that will drop all policy updates. This can be used in situations where you want to skip the default IAM permission adding behavior of CDK. Needs only be used with roles that are created in the same CDK application; for imported roles, supplying `mutable=false` when calling `Role.fromRoleArn()` is sufficient. Fixes #2985. Fixes #4465. Closes #4501.

skinny85 requested a review from rix0rrr October 14, 2019 23:40

SomayaB assigned rix0rrr Oct 15, 2019

SomayaB added the contribution/core This is a PR that came from AWS. label Oct 15, 2019

rix0rrr reviewed Oct 16, 2019

View reviewed changes

eladb reviewed Oct 16, 2019

View reviewed changes

skinny85 force-pushed the fix/immutable-role branch from a47c6e2 to cfd8a27 Compare October 18, 2019 00:38

skinny85 force-pushed the fix/immutable-role branch from cfd8a27 to f40edeb Compare October 21, 2019 22:17

skinny85 added 2 commits October 22, 2019 20:16

Implement LazyPolicy.

021bc24

skinny85 force-pushed the fix/immutable-role branch from f40edeb to 021bc24 Compare October 23, 2019 03:16

rix0rrr reviewed Oct 23, 2019

View reviewed changes

Implement LazyPolicy in terms of a new 'deleteChild'.

f8d7acc

skinny85 commented Oct 30, 2019

View reviewed changes

Switch to using L2 dependency mechanism

5590237

Merge branch 'master' into fix/immutable-role

04b9569

Document deleteChild.

e843694

rix0rrr mentioned this pull request Dec 27, 2019

feat(iam): Role.withoutPolicyUpdates() #5569

Merged

rix0rrr closed this Dec 27, 2019

	class ImmutableImport extends Import {
	public addToPolicy(_statement: PolicyStatement): boolean {
	return false;
	}

	public attachInlinePolicy(_policy: Policy): void {
	// do nothing
	}
	}

feat(iam): immutable IAM roles #4501

feat(iam): immutable IAM roles #4501

Conversation

skinny85 commented Oct 14, 2019 • edited Loading

mergify bot commented Oct 14, 2019

skinny85 commented Oct 14, 2019

aws-cdk-automation commented Oct 15, 2019

AWS CodeBuild CI Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

skinny85 Oct 17, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

skinny85 Oct 21, 2019 • edited Loading

Choose a reason for hiding this comment

rix0rrr Oct 22, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eladb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

skinny85 Oct 18, 2019 • edited Loading

Choose a reason for hiding this comment

skinny85 commented Oct 18, 2019

aws-cdk-automation commented Oct 18, 2019

AWS CodeBuild CI Report

skinny85 commented Oct 21, 2019

aws-cdk-automation commented Oct 21, 2019

AWS CodeBuild CI Report

aws-cdk-automation commented Oct 23, 2019

AWS CodeBuild CI Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

skinny85 commented Oct 25, 2019

rix0rrr commented Oct 28, 2019

aws-cdk-automation commented Oct 28, 2019

AWS CodeBuild CI Report

skinny85 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rix0rrr commented Oct 30, 2019

rix0rrr commented Oct 30, 2019

aws-cdk-automation commented Oct 30, 2019

AWS CodeBuild CI Report

aws-cdk-automation commented Oct 30, 2019

AWS CodeBuild CI Report

aws-cdk-automation commented Oct 30, 2019

AWS CodeBuild CI Report

skinny85 commented Oct 30, 2019 • edited Loading

skinny85 commented Oct 30, 2019

rix0rrr commented Oct 31, 2019

skinny85 commented Oct 31, 2019

mergify bot commented Dec 16, 2019

mergify bot commented Dec 16, 2019

mergify bot commented Dec 16, 2019

mergify bot commented Dec 16, 2019

mergify bot commented Dec 16, 2019

mergify bot commented Dec 16, 2019

rix0rrr commented Dec 27, 2019

skinny85 commented Oct 14, 2019 •

edited

Loading

skinny85 Oct 17, 2019 •

edited

Loading

skinny85 Oct 21, 2019 •

edited

Loading

rix0rrr Oct 22, 2019 •

edited

Loading

skinny85 Oct 18, 2019 •

edited

Loading

skinny85 commented Oct 30, 2019 •

edited

Loading