cri-tools

cri-tools copied to clipboard

What type of PR is this?

/kind feature

What this PR does / why we need it:

The crictl pull subcommand now supports the --verify-signature, -s command to verify cosign signatures, which will be shipped for the official Kubernetes images from v1.24.0. This allows other tools to verify the signatures on the fly before pulling the image.

Please note that providing the flag will not fail if no signature is present, only if it's invalid.

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

Refers to https://github.com/kubernetes/release/issues/2383

Does this PR introduce a user-facing change?

Added `crictl pull --verify-signature, -s` subcommand to verify cosign signatures of container images.
Please note that providing the flag will not fail if no signature is present, only if it's invalid.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: saschagrunert

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~~ [saschagrunert]

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

CI fix in https://github.com/kubernetes-sigs/cri-tools/pull/907

@feiskyer @mrunalp @mikebrow what do you think, do we wanna take such a feature in?

+1 to have this

Rebased, PTAL @feiskyer :)

@feiskyer @mrunalp @mikebrow what do you think, do we wanna take such a feature in?

a few thoughts/questions.. apologies for not being up to date with your progress on this

1. +1 to have this done somewhere in the stack, just not sure it's the right fit for crictl

2. This project scope change probably needs approval of some sort from the sponsor: https://github.com/kubernetes-sigs/cri-tools#what-is-the-scope-of-this-project

3. Doing the check in crictl is no guarantee the runtime will use the same resolve path or get the same image unless we at least do some sha verification between what is being pre-checked and the image pulled.

4. I guess this route will not work for situations where the container runtime does the pull, or if import is used. If the status of the image is already on node.. should there be a check/verify and remove api? Should there be a record of the time, then do re-checks on some intermittent basis or is this version of verify a permanent result regardless of time, ...

5. In my mind this sort of tooling was either going to be done in a higher level client context (kubelet image manager or admission controller) and/or through a set of policies passed down through the CRI and possibly handled through an extension in the distribution api enabled by with the registries/artifact providers to reduce traffic overload.

@saschagrunert: PR needs rebase.

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.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

@k8s-triage-robot: Closed this PR.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/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.

FWIW now that this issue's gone stale: I agree this seems like more of something one would configure in the runtime, unless the CRI becomes signature aware