[Action, Green Reviews WG] Define access control management process for Green Reviews infra

[guidemetothemoon]

Description

Now that Green Reviews WG has got access to the dedicated infrastructure on Equinix we need to establish a process to give access to this infrastructure to those who need it. Once the process it outlined we can put it in writing.
For now we can have a dedicated section for this in the CNCF TAG ENV – WG Green Reviews Design Document

• Who should get access and how?
• For how long?
• How to ask for access in a transparent and lightweight manner?
• Clean up access when not needed?
• Other concerns?

Input

Need input on the questions provided above so that we can define the process in writing.

Outcome

Formally defined process for access control management and requesting access to the Green Reviews WG infrastructure.

[leonardpahlke]

@RobertKielty can this be part of CLOwarden? or do we need to manage infra access via equinix console / api "manually"

[RobertKielty]

CLOWarden is used to govern access to just GitHub repos at the moment.

I like the way you're thinking though! Long term, the vision is to create plugins to have CLOWarden control access to multiple services. We're not there yet though.

[nikimanoledaki]

Hey @Callisto13 (who does awesome stuff in general & currently at Equinix)!

We got access to an Equinix project. Our immediate next step is to start provisioning a Kubernetes cluster using Cluster API. We're looking at potentially using the Equinix Metal Cluster API provider (CAPEM). The configuration will live in this tooling repo: https://github.com/cncf-tags/green-reviews-tooling

Adding you to this thread to ask if you have any Equinix CAPI pro tips, Equinix auth suggestions, Equinix dev advocate contacts, awesome tooling suggestions in general and/or any other pointers!

[Callisto13]

👋 hey @nikimanoledaki

I'm afraid I don't have any hot tips for CAPEM, but it looks about the same as any other CAPI provider 😄 .

As for Auth to your hardware, I am guessing y'all have a project under the CNCF org? That would give you 2 access options:

1. Full console access, where you invite people to join the org as a "limited collaborator" with access to that project only.
2. Programmatic access, where you create a "bot" limited collaborator user with access to that project, then issue project level API keys for users.

Neither of these have expiry options, so you'd have to manage when to revoke access. Or write some code around adding and automatically removing people, which should be fairly trivial.

(A third way would be to create the machines you know you want to use and have a nice automated way of adding people's SSH keys, that way they would not need an Equinix account. This is assuming you either keep public IPs on the devices or have a VPN or tunnel etc. This would limit them to the servers only and gives you slightly more granular access for people who don't need any more than that.)

Lmk if you have any hardware questions 😀

[nikimanoledaki]

Thank you @Callisto13 for outlining our auth options! 🎉 The 2 WG co-chairs (@guidemetothemoon and I) as well as 2 TAG leads (@mkorbi & @leonardpahlke) were added by the CNCF folks to the dedicated project for the TAG Environmental Sustainability (this is a manual process that we don't have control over so we're trying to limit doing this). This means 4 of us currently have (option 1) full console access for now - unsure if/how we would extend access. Perhaps we could create new roles (e.g. Sustainability Reviewer) to extend access to more individual contributors. For everything else, we will most likely go with (option 2) project-level API keys added to the repository. We will try to rely on IaaS tooling as much as possible to make changes through PRs (yay GitOps!). With regard to which tooling, the state of our infrastructure decisions is outlined here. We're still very much in the planning phase.

With regard to the hardware, the first CNCF Project that we will test is Falco, which is a security- and eBPF-based tooling. We will be using Kepler, which is also eBPF-based, so we have a few kernel-level requirements. We're starting with the Falco requirements outlined here. If you have any pointers for getting started on which hardware to provision and how to do so given these requirements, we would be very grateful!

[leonardpahlke]

Do we really need to grant other access to Equinix setup? Perhaps read access for some logs. If we define the deployment infra in the repo (with OpenTofu or similar 😉) and deploy via CI/CD - anyone can propose config changes, we just need to review and approve the PRs.

[nikimanoledaki]

Update - here is the process that we are using at the moment:

• WG Chairs created a Project API Key in the Equinix Project.

Project-level API keys can be added to a project to allow access to the Equinix Metal API that is not tied to a particular user. Project API keys do not have access to the entirety of the API; some endpoints can only be used by personal API tokens.

• WG Chairs privately share the Project ID (from project settings) as well as the API key token, which has read/write access, with individual contributors.

This has helped to unblock individual contributors with manual testing. We will update this once we have consensus on the IaC component and start implementing it.

[nikimanoledaki]

Update

This issue is mostly completed and documented in the draft of the design doc here.

Clean up access when not needed?

We should revoke access when offboarding a TAG lead - not sure if offboarding is documented since the TAG is still relatively new and we haven't gone through that process yet but just something to keep in mind! cc TAG Chairs @leonardpahlke @catblade @mkorbi

Adding the API key as a secret to the green-reviews-tooling repository is tracked in this POC: cncf-tags/green-reviews-tooling#6

We can keep this issue open while we still work on the draft.

[nikimanoledaki]

Closing this issue since we're tracking specific access-related issues in the WG repo https://github.com/cncf-tags/green-reviews-tooling