Add AWS registry infra terraform

[BobyMCbobs]

Adds Terraform to provision a bucket in s3 for kpromo tests

[puerco]

Thanks @BobyMCbobs, I'm humbled to get a piece of infra after me!

However, the idea of this bucket is to use it for the container image promoter unit tests. WDYT if we rename everything kpromo-* to make it more related to the actual project that will use it?

[BobyMCbobs]

Thanks @BobyMCbobs, I'm humbled to get a piece of infra after me!
However, the idea of this bucket is to use it for the container image promoter unit tests. WDYT if we rename everything kpromo-* to make it more related to the actual project that will use it?

@puerco, I'm all for naming things for their purpose! kpromo FTW!
Updated in b0a1559

[ameukam]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ameukam, BobyMCbobs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ameukam]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ameukam]

@BobyMCbobs Is it possible to use the Markdown format for all the docs ? Let's use a format well adopted by the community.

[BobyMCbobs]

Swapped out the format in e02cb71

[ameukam]

We should also make sure release admins have access to this account :

k8s.io/groups/sig-release/groups.yaml

Line 18 in 8a1b9d2

- email-id: k8s-infra-release-admins@kubernetes.io

[eddiezane]

I think this needs both the bucket and its sub resources to work.

[arn:aws:s3:::test, arn:aws:s3:::test/*]

[BobyMCbobs]

Updated in 2dcf793

[ameukam]

@BobyMCbobs -- Suggestions for this PR:

• Create a new AWS account under the same AWS organisational as the account requested here using an email accessible by the SIG Release Chairs/TLs. (possibly sig-release-leads@kubernetes.io). I suggest to enable MFA for this account once it's done.
• Create individual account and give permissions with the built-in policy arn:aws:iam::aws:policy/AdministratorAccess to every member of this list :

  k8s.io/groups/sig-release/groups.yaml

  Lines 18 to 29 in 8a1b9d2

  	- email-id: k8s-infra-release-admins@kubernetes.io
  	name: k8s-infra-release-admins
  	description: |-
  	ACL for Release Engineering subproject owners (partial admin access to Release GCP projects)
  	https://git.k8s.io/sig-release/release-managers.md
  	settings:
  	ReconcileMembers: "true"
  	members:
  	- adolfo.garcia@uservers.net
  	- ctadeu@gmail.com
  	- k8s@auggie.dev
  	- saschagrunert@gmail.com

  .

[BobyMCbobs]

@BobyMCbobs -- Suggestions for this PR:

• Create a new AWS account under the same AWS organisational as the account requested here using an email accessible by the SIG Release Chairs/TLs. (possibly sig-release-leads@kubernetes.io). I suggest to enable MFA for this account once it's done.
• Create individual account and give permissions with the built-in policy arn:aws:iam::aws:policy/AdministratorAccess to every member of this list :

  k8s.io/groups/sig-release/groups.yaml

  Lines 18 to 29 in 8a1b9d2

  	- email-id: k8s-infra-release-admins@kubernetes.io
  	name: k8s-infra-release-admins
  	description: |-
  	ACL for Release Engineering subproject owners (partial admin access to Release GCP projects)
  	https://git.k8s.io/sig-release/release-managers.md
  	settings:
  	ReconcileMembers: "true"
  	members:
  	- adolfo.garcia@uservers.net
  	- ctadeu@gmail.com
  	- k8s@auggie.dev
  	- saschagrunert@gmail.com

  
  .

@ameukam, thank you for your suggestions.
I think the scope of regular AWS accounts is not well suited to this action, due to the accounts being isolated and not exactly nested.
Perhaps IAM users is better, so that they have access inside the k8s-infra-aws-root-account@kubernetes.io account.
From my explorations in AWS accounts and orgs:

• AWS accounts are all at the same level
• billing is required to create separate AWS accounts
• adding AWS accounts to access other AWS accounts requires access to the k8s-infra-aws-root-account@kubernetes.io

That said in order to make IAM accounts, some Terraform will need to run against the k8s-infra-aws-root-account@kubernetes.io to provision inside it.
IAM users will mean for:

• easier user management
• everyone lives out of the same account
  • billing isn't a concern to the IAM users
• no having to deal with the perils of real accounts
  • email invitations, etc..
  • no prompts for validating if you're a human
• MFA is available too!

[ameukam]

adding AWS accounts to access other AWS accounts requires access to the k8s-infra-aws-root-account@kubernetes.io

I don't think this is necessary. The account created using this e-mail is independent and the AWS accounts should be in the same OU.

some Terraform will need to run against the k8s-infra-aws-root-account@kubernetes.io to provision inside it.

You can setup an new AWS account using sig-release-leads@kubernetes.io and run the HCL code against it.

[hh]

I'm concerned that we are creating completely isolated accounts that will be difficult to manage, audit, and replicate the way in which we work to other CNCF projects.

Might be good to get some AWS experts in, maybe we can get some input from @sftim? I’ve asked @eddiezane and hoping to get an AWS Solutions Architectect permanently assigned to the CNCF Cloud Credits / #sig-k8s-infra if possible.

I am reluctant to make this kind of irrevocable call with regards to account structure without wider input. So far everything is a sandbox, this is a move to permanent production.

@sftim Are you available for a sync with @ameukam or can you help weigh in here?

[sftim]

I'll follow this up on Slack to discuss availability.

[dims]

@hh i would like us to time box this discussion. I am concerned about other CNCF projects for sure, but we can rework this stuff until we get this to production, so i am not worried as much. Note that other CNCF projects should not get in the way of us doing what we need to do right now to reduce our cost. please take that into consideration when making decisions. other projects are not in the same position as us.

[hh]

Absolutely @dims! I'm meeting with @jaypipes first thing Monday to see if we can get an AWS Solutions Architect assigned to help with #sig-k8s-infra ongoing to help us with designs decisions like this.

To unblock and keep velocity, Caleb went ahead and created the account as requested.

Note that the OU is kubernetes-2022-q1, to denote both of the OU and accounts as temporary.

The pattern we seem to be initiating is a new account per sig, within the Kubernetes OU, alasig-X-leads@kubernetes.io. This would need to be initiated from the CNCF root account instead of a Kubernetes level account. I'm not sure this is what we want long term, and want to be sure we can back out and change direction later.

As it stands, when we create a new account, we lack a process and policy to setup some auditing and visibility for that account. Looking forward to seeing this evolve and move forward!

[ameukam]

@BobyMCbobs @hh We should close this one. #3605 create the production buckets and the needed IAM role and user.

[BobyMCbobs]

Closing in favor of #3605.

Will reopen or open a new PR for account infra related stuff as discussed in the last sig-k8s-infra meeting

[BobyMCbobs]

/close

[k8s-ci-robot]

@BobyMCbobs: Closed this PR.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.