kep: image promoter: process to copy container images

[javier-b-perez]

KEP to create a process for publishing container images into the official kubernetes container registry.

[cblecker]

/ok-to-test
/cc @ixdy @dims

[dims]

@javier-b-perez wanted to raise this question. As part of the promotion, do we want to sign the images? please see

• Enable content trust for k8s.gcr.io kubernetes#63704
• https://docs.docker.com/engine/security/trust/content_trust/

[BenTheElder]

Thanks @javier-b-perez! Initial pass LGTM 😄

[javier-b-perez]

@javier-b-perez wanted to raise this question. As part of the promotion, do we want to sign the images? please see

• kubernetes/kubernetes#63704
• https://docs.docker.com/engine/security/trust/content_trust/

That is a good point, I will investigate if this is possible and if we can, I think we should sign during the promotion process.

[thockin]

Idea LGTM. Who else do we want to look at this? @kubernetes/sig-release-members maybe ?

[dims]

Needs a small update after looking at signing possibilities. LGTM otherwise.

[javier-b-perez]

Needs a small update after looking at signing possibilities. LGTM otherwise.

Looking at GCR seems it is not supported at the moment, but we can still push to multiple registries, if we want, (like GCR, docker hub) and sign images when possible as part of the promotion process.
I will update the text with a comment saying that as part of the promotion process, we could sign images.

[thockin]

Before approving this, I really want some of the release folks to review.

…

On Fri, Sep 21, 2018 at 11:10 AM k8s-ci-robot ***@***.***> wrote: [APPROVALNOTIFIER] This PR is *NOT APPROVED* This pull-request has been approved by: To fully approve this pull request, please assign additional approvers. We suggest the following additional approver: *thockin* If they are not already assigned, you can assign the PR to them by writing /assign @thockin in a comment when ready. The full list of commands accepted by this bot can be found here <https://go.k8s.io/bot-commands>. The pull request process is described here <https://git.k8s.io/community/contributors/guide/owners.md#the-code-review-process> Needs approval from an approver in each of these files: - *keps/OWNERS <https://github.com/kubernetes/community/blob/master/keps/OWNERS>* Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#2695 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVBdIx4cztWH1cDQ3unXGiISJYDRyks5udSuggaJpZM4Wyqzn> .

[tpepper]

We're mulling perhaps something for a larger KEP around an improved release engineering process and possible connections to SIG Testing improvements as things transition out from under Google to CNCF.

[thockin]

Larger than this proposal? Inclusive of this or different than this?

…

On Tue, Sep 25, 2018 at 2:26 PM Tim Pepper ***@***.***> wrote: We're mulling perhaps something for a larger KEP around an improved release engineering process and possible connections to SIG Testing improvements as things transition out from under Google to CNCF. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2695 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVBjFpLuY7yexsg2B2w5cJbMI9huHks5uep93gaJpZM4Wyqzn> .

[dims]

@tpepper what's detailed here in this KEP will be an important part of whatever we come up with for a "larger KEP around an improved release engineering". So i'd like to get this approved.

/cc @AishSundar @calebamiles @kubernetes/k8s-infra-team

[AishSundar]

Thanks @javier-b-perez this LGTM, just had a minor comments.

[justaugustus]

/kind kep

[mkumatag]

How do we do this now? can we control access to the individual images vs directory?

[javier-b-perez]

We cannot control individual images or directories in GCR. This is why I say it should be a "small set of members".
We can restrict who can merge or approve PR into the manifest's repository, then leave the rest to the promoter tool). So those who approve PRs don't even need to have write access into the container registry.

[thockin]

@javier-b-perez Would it make sense to have each sub-project get a new staging area of their own, and have the promoter pull from any of those?

I guess we'd need a new GCP project for each bucket (I can't see how to make >1 bucket in a project). The promoter works on hash, so it should Just Work, right?

[javier-b-perez]

@thockin it is possible to have a per project staging container registry, that means we need to create a GCP project per each GCR we want to handle.
The promoter tool just need read access to this GCR and it can copy the container image with the same digest from project staging to official container registry.

How do you see the staging domain working? something like:
staging-k8s.gcr.io/project1/imageA -> GCR/project1/imageA
staging-k8s.gcr.io/project2/imageB -> GCR/project2/imageB
(not sure if this is possible, might not)

[thockin]

I'm just thinking out loud. The options are really

a) Be careful who can push because anyone who can write can do anything.

b) Give each sub-team their own space.

e.g. gcr.io/k8s-foo-staging for project foo and gcr.io/k8s-bar-staging for project bar, both promote to gcr.k8s.io/{foo,bar}/{foo,bar}:<tag>

@dims @mkumatag thoughts?

[thockin]

I don't think we can do permissions less than a whole bucket. Does it make sense to consider a federation of buckets that people can use as their staging and have the promoter be able to promote from any of them?

…

On Fri, Oct 12, 2018 at 8:22 PM Manjunath A Kumatagi < ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In keps/sig-release/0028-k8s-image-promoter.md <#2695 (comment)>: > + * [Promotion Process](#promotion-process) +* [Graduation Criteria](#graduation-criteria) +* [Infrastructure Needed](#infrastructure-needed) + + +## Summary + +For security reasons, we cannot allow everyone to publish container images into the official kubernetes container registry. This is why we need a process that allows us to review who built an image and who approve it to be shown in the official channels. + + +## Motivation + +There are multiple reasons why we should have a process to publish container images in place: + +* We cannot allow all community members to publish images into the official kubernetes container registry. +* We should restrict who can push images to a small set of members and some systems accounts for automation. How do we do this now? can we control access to the individual images vs directory? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2695 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVIwvg7sdP-sDzmQL05a8gOf4fhALks5ukVxrgaJpZM4Wyqzn> .

[listx]

I'd like to state for the record (please let it be known!!) that I'm highly interested in creating a demo of a promotion tool to help realize this KEP. It would be responsible for performing various promotions and whatnot.

I should have a proof-of-concept ready before the end of the year.

[listx]

@calebamiles What will it take to get this KEP approved?

[dims]

@listx i think we need approval from @thockin as mentioned in the proposal itself :)

[listx]

@dims Oops, I completely missed the metadata part.

As a reviewer myself, LGTM.

[thockin]

/lgtm
/approve

[calebamiles]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: calebamiles, thockin

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:

• keps/OWNERS [calebamiles]

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