add optional policy allowing push access

[kpankonen]

what

• adds the ability to give push-only access to the repository

why

• full access was more than we wanted in our situation (CI pushing images to the repo) so we added a principals_push_access to give push-only access.

references

• policy is based on this AWS doc

[ngoyal16]

#96

[nitrocode]

/test all

[nitrocode]

Thanks for the contribution. I'm just trying to get a second set of eyes on this to make sure it's what we want in this module.

[ngoyal16]

Use distinct function for override policy document

[ngoyal16]

Either we should move lambda condition to independent or add in push policy as welll

I prefer it should be independent

[kpankonen]

Use distinct function for override policy document

I'm not sure I follow. Where do you think there should be a distinct function?

[ngoyal16]

Use distinct function for override policy document

I'm not sure I follow. Where do you think there should be a distinct function?

Main.tf line no 250

[kpankonen]

Use distinct function for override policy document

I'm not sure I follow. Where do you think there should be a distinct function?

Main.tf line no 250

Maybe I'm missing something but I think that would require restructuring the module so that the all (push, readonly, full)actions are combined/distinct before they get used in a policy document. That would also mean losing the sid on the different policy blocks. That would make it harder to understand the policy when looking at it from the AWS side.

Or I'm looking at the wrong thing...

[ngoyal16]

Suggested change

	override_policy_documents = [
	override_policy_documents = distinct([])

[nitrocode]

You mean to wrap distinct([ around lines 253 and 254 ?

[ngoyal16]

Yes

[ngoyal16]

Also adding lambda principal policy as whole would be great so if someone wants a repo with lambda ran can be done as well without others statements policy

[kpankonen]

i see the bridgecrew code analysis is failing but i'm not able to see the output of the job

[nitrocode]

/test all

[aknysh]

@kpankonen please see comments

[aknysh]

please see comments

[ngoyal16]

@kpankonen currently lambda access is granted using dynamic statements in each group and it may be problematic if someone want to create and ECR with just lambda access as resource policy. then policy might be missing because we are checking if the system has push or pull or full variables then only create not based on lambda too. We should have independent staement for lambda access policy.

[kpankonen]

@aknysh @nitrocode is there anything else i can do to help get this merged?

[aknysh]

/test all

[aknysh]

/rebuild-readme

[aknysh]

/test all

[kpankonen]

@kpankonen Apologies, but can you fix the out of date README? Do the following:

make init
make github/init
make readme

and commit the changes (if any)

done!

[joe-niland]

/test all

[kpankonen]

anything else needed?

[Gowiem]

Argh @kpankonen -- we're doing you wrong here with multiple of us trying to move it forward, but then dropping the ball (we get drowned in a sea of GH notification emails as part of being on the maintainer team, so that is our excuse 😅 ).

Can you please address the conflicts or try rebasing again? Once this is ready to go, ping me here or better yet in the SweetOps slack and I will be sure to get this over the line for you. Thanks for the work and patience!

[Gowiem]

/terratest

[kpankonen]

@Gowiem updated

[Gowiem]

/terratest

[Gowiem]

[Gowiem]

@aknysh I believe we need your approval to move this forward.

FYI, I am going to do a fast follow on this PR today or tomorrow to break out the principals_lambda policies into their own policy doc so they don't need to be included with each of these full vs read vs write docs.