KEP-6051: CRI Streaming Authorization Hook

[mattsu2020]

Summary

Adds a KEP proposing an optional AuthorizeStream hook to the CRI streaming server configuration (k8s.io/cri-streaming). The hook is invoked after a short-lived stream URL token is validated and before exec, attach, or port-forward streams are served.

Enhancement issue: #6051
Code PR: kubernetes/kubernetes#138616

Motivation

The CRI streaming package currently relies entirely on a single-use, short-lived random token for stream request security. There is no authentication or authorization at the streaming server level, as noted by the long-standing TODO:

// TODO(tallclair): Add auth(n/z) interface & handling.
func NewServer(config Config, runtime Runtime) (Server, error) {

This KEP addresses that gap by providing a stream-time authorization hook that CRI runtime implementers can use for:

• Defense in depth at the CRI shim boundary
• Audit logging for compliance
• Custom runtime-specific authorization policies

Key Design Decisions

• AuthorizeStream func(http.ResponseWriter, *http.Request) error added to streaming.Config
• When nil (default), existing behavior is preserved — fully backward-compatible
• Called after token validation, before stream serving
• Rejected requests return 403 Forbidden

SIG Node Discussion

Initial feedback from @mikebrow on kubernetes/kubernetes#138616 requested a KEP with solid use cases and comprehensive integration tests. This KEP addresses those requirements.

[k8s-ci-robot]

Welcome @mattsu2020!

It looks like this is your first PR to kubernetes/enhancements 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/enhancements has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mattsu2020
Once this PR has been reviewed and has the lgtm label, please assign dchen1107 for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• keps/sig-node/OWNERS

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

[k8s-ci-robot]

Hi @mattsu2020. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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-sigs/prow repository.

[aojea]

I'm unclear on how this works with the current kubernetes setup, IIRC the decision to split the streaming bits from cri was to simplify dependencies.
This proposal seems that is trying to make this module generic and build a library or at least I miss how the kubelet will use this new hook

[mattsu2020]

I'm unclear on how this works with the current kubernetes setup, IIRC the decision to split the streaming bits from cri was to simplify dependencies. This proposal seems that is trying to make this module generic and build a library or at least I miss how the kubelet will use this new hook

Thanks, that is a fair point.

My intent was to add a stream-time authorization point for CRI streaming server embedders, but I agree the current proposal does not clearly show how this fits into the current kubelet/CRI flow. In the current Kubernetes setup, kubelet authorizes the original exec/attach/port-forward request and then proxies to the URL returned by the runtime; kubelet does not directly construct the cri-streaming server config in the usual path.

Given that, the proposal is currently underspecified. I need to either describe a concrete kubelet-facing integration, including what identity/authorization context would be propagated to the runtime stream server, or narrow/withdraw the proposal if this is only a generic library hook without an in-tree Kubernetes use case.

I will revisit the KEP with that in mind.