UserInfo.UID is not passed by client-go

[reith]

It looks UserInfo.UID is newer than other fields and while #49677 added it SubjectAccessReviewSpec for webhook authorization, it's still not being sent by client-go in headers. Also there is no flag in APIServer to process those headers. As a result all authorizers needing that, may not work correctly for SubjectAccessReviews made by kube-aggregator extensions.

What happened:

Our webhook authorizer, authorizes users using UserInfo.UID. It's missing in SubjectAccessReviews created by kube-aggregator extensions (our case was state metrics), resulting authorizer to not work.

What you expected to happen:

I except All fields that is filled by authenticator be present for authorizer and I think it's valid to have an authorizer to use UID.

How to reproduce it (as minimally and precisely as possible):

Make authentication webhook that fills SubjectAccessReviewSpec.UID. You will see there UID is missing from SubjectAccessReviewSpecs made by a kube-aggregator extension.

Anything else we need to know?:

UserInfo.UID is not passed to client-go round-tripper here and here and impersonate config do nothing for it. There is also no api-server flag to get it from headers.

[reith]

/sig auth
/sig api-machinery

[caesarxuchao]

cc @lavalamp @deads2k

[lavalamp]

cc @liggitt @mikedanese @enj

[MonzElmasry]

Hey 👋 Bug Triage here. Wanted to follow up on the status of this issue as we're approaching code freeze on 12.11.2020. This issue is tagged for 1.20, is it still planned for this release?

[liggitt]

no, it is not

/milestone clear

[carlory]

/cc @carlory

[enj]

/assign

I need to break down the different pieces of work required to fix this.

[enj]

There are two main tracks of work.

UID impersonation (assigned to @margocrawf)

1. Server side Impersonate-Uid header support Introduce Impersonate-UID header #99961
2. Update both rest.ImpersonationConfig and transport.ImpersonationConfig to allow a UID to be specified
3. Add --as-uid CLI flag to kubectl
4. (maybe) Add --as-extra CLI flag to kubectl

UID request header (assigned to @benjaminapetersen)

1. Add new requestheader-uid-headers CLI flag, wire it through the stack
2. Update the kube-system/extension-apiserver-authentication config map to include a new requestheader-uid-headers data key that matches the value set for the CLI flag
3. Update delegated authentication logic to honor the new config map data key
4. Update headerrequest.NewDynamicVerifyOptionsSecure and related code to take a new headerrequest.StringSliceProvider as input to wire through the UID header config
5. Wire UID header through SetAuthProxyHeaders and its callers

/assign @margocrawf @benjaminapetersen

[k8s-ci-robot]

@enj: GitHub didn't allow me to assign the following users: margocrawf, benjaminapetersen.

Note that only kubernetes members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

There are two main tracks of work.

UID impersonation (assigned to @margocrawf)

1. Server side Impersonate-Uid header support Introduce Impersonate-UID header #99961
2. Update both rest.ImpersonationConfig and transport.ImpersonationConfig to allow a UID to be specified
3. Add --as-uid CLI flag to kubectl
4. (maybe) Add --as-extra CLI flag to kubectl

UID request header (assigned to @benjaminapetersen)

1. Add new requestheader-uid-headers CLI flag, wire it through the stack
2. Update the kube-system/extension-apiserver-authentication config map to include a new requestheader-uid-headers data key that matches the value set for the CLI flag
3. Update delegated authentication logic to honor the new config map data key
4. Update headerrequest.NewDynamicVerifyOptionsSecure and related code to take a new headerrequest.StringSliceProvider as input to wire through the UID header config

/assign @margocrawf @benjaminapetersen

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.

[enj]

/unassign @mikedanese
/remove-help

[benjaminapetersen]

/assign

[moficodes]

@enj @stlaz
1.28 Bug Triage Shadow here.

Just checking-in (it is still early in the release cycle, no rush at all) if this is still on track for the 1.28 release?

[furkatgofurov7]

@reith @enj @dims hi folks, 1.28 Bug Triage Lead here 👋🏼

This issue has not been updated for a long time, so I'd like to check what's the status and if there are plans moving it forward. Please be aware that the code freeze is starting 01:00 UTC Wednesday 19th July 2023 / 18:00 PDT Tuesday 18th July 2023 (about less than 2 weeks from now).

As the issue is tagged for 1.28, is it still planned for this release?

[stlaz]

Howdy 👋
The linked PR is waiting for a review. I believe it's the last PR before we'd able to close this issue.

[moficodes]

Week 9 update: Code Freeze is approaching!

Hey! We are currently in Week 9, and Code Freeze is just over a week away. It will begin at 01:00 UTC on Wednesday, 19th July 2023 / 18:00 PDT on Tuesday, 18th July 2023. Please ensure all necessary submissions are made before the deadline. Let me know if you need any assistance. :)

[enj]

Howdy 👋 The linked PR is waiting for a review. I believe it's the last PR before we'd able to close this issue.

Sadly missed code freeze on this one.

/milestone next-candidate

[enj]

/milestone v1.29

[moficodes]

Hello @enj ! 👋🏼
Bug triage for the 1.29 release cycle is here!
This issue hasn't been updated for a long time, so I wanted to check what the status is. The code freeze will start (01:00 UTC Wednesday 1st November 2023 / 18:00 PDT Tuesday 31st October 2023), which is about 2 weeks from now. And while there is still plenty of time, we want to make sure that every PR has a chance to be merged on time.

As the issue is tagged for 1.29, is it still planned for that release?

[moficodes]

Hello @enj ! 👋🏼
Bug triage for the 1.29 release cycle is here!
This issue hasn't been updated for a long time, so I wanted to check what the status is. The code freeze will start (01:00 UTC Wednesday 1st November 2023 / 18:00 PDT Tuesday 31st October 2023), which is this week. We want to make sure that every PR has a chance to be merged on time.

As the issue is tagged for 1.29, is it still planned for that release?

[dims]

/milestone v1.30

kicking the can, we are way past code freeze

[SubhasmitaSw]

Hi there! 👋🏼
Release Signal shadow here.
This issue has not been updated for a long time, so I'd like to check the status. The code freeze is starting 02:00 UTC Wednesday 6th March 2024 / 18:00 PDT Tuesday 5th March 2024 (less than 2 weeks from now), and while there is still some time, we want to ensure that each PR has a chance to be merged on time.

Is this issue still intended for this release, given that it is labeled for 1.30?

[moficodes]

Hello!
Release Signal shadow here.
I'd like to check what's the status. The code freeze is starting 02:00 UTC Wednesday 6th March 2024 / 18:00 PDT Tuesday 5th March 2024 in a week, and we want to ensure that each PR has a chance to be merged on time.

[Vyom-Yadav]

We are past the code freeze stage. Moving this to the next release.

/milestone v1.31

[wendy-ha18]

Hello @enj ! This issue has not been updated for a long time, so I'd like to check what's the status. The code freeze is starting 02:00 UTC Wednesday 10th July 2024 (about 4 weeks from now), and while there is still plenty of time, we want to ensure that each PR has a chance to be merged on time.

As the issue is tagged for 1.31, is it still planned for this release?

[wendy-ha18]

Hello @enj @stlaz

This issue hasn't been updated in a while. What's the current status?

Reminder: Code freeze starts 02:00 UTC Wednesday 24th July 2024 / 19:00 PDT Tuesday 23rd July 2024 (about 1.5 weeks from now). Please make sure the linked PR #115834 has both lgtm and approved labels before the code freeze.

[stlaz]

Hello Wendy,
The PR got recently reviewed and I'm addressing the comments but the work will most likely slip into the next release.

[enj]

/milestone v1.32