Skip to content

Conversation

@enj
Copy link
Member

@enj enj commented Feb 3, 2026

/assign deads2k liggitt qiujian16

Signed-off-by: Monis Khan <mok@microsoft.com>
@k8s-ci-robot
Copy link
Contributor

@enj: GitHub didn't allow me to assign the following users: qiujian16.

Note that only kubernetes members with read permissions, 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

Details

In response to this:

/assign deads2k liggitt qiujian16

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.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Feb 3, 2026
@k8s-ci-robot k8s-ci-robot added kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/auth Categorizes an issue or PR as relevant to SIG Auth. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Feb 3, 2026
@enj enj mentioned this pull request Feb 3, 2026
8 tasks
@enj enj added this to SIG Auth Feb 4, 2026
@enj enj moved this to Needs Triage in SIG Auth Feb 4, 2026
These will be expanded to include metrics that cover the impersonation handler
to give an overall sense for the cost of impersonation:

- apiserver_impersonation_attempts_total (success per mode or failure)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because we're planning to check the new modes first, existing users of legacy impersonation would show up as metric failures for the constrained modes, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or are you suggesting we would only record success-per-mode, or failure (not failure-per-mode)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or are you suggesting we would only record success-per-mode, or failure (not failure-per-mode)?

talked offline, this was the intent

update this to make that clearer, then lgtm

These will be expanded to include metrics that cover the impersonation handler
to give an overall sense for the cost of impersonation:

- apiserver_impersonation_attempts_total (success per mode or failure)
Copy link
Member

@liggitt liggitt Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we answer the question "how many requests successfully impersonated" and "how many requests attempted impersonation and failed impersonation" without regard for the constrained-mode → legacy fallback? because we do fallbacks (associated-node → any-node → legacy), I'm trying to figure out how we would interpret failure counts per mode

for example, if failed impersonations prior to this feature are at X% and failed impersonations with the feature enabled are at 2X%, that would seem significant

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

talked offline, failure metrics weren't per-mode... update this to make it clearer (explicitly listing the labels and values will help), then lgtm

Comment on lines 32 to 35
- apiserver_impersonation_attempts_total
- apiserver_impersonation_duration_seconds
- apiserver_impersonation_authorization_attempts_total
- apiserver_impersonation_authorization_duration_seconds
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@deads2k
Copy link
Contributor

deads2k commented Feb 11, 2026

Once updates already noted are made, lgtm.

Signed-off-by: Monis Khan <mok@microsoft.com>
@deads2k
Copy link
Contributor

deads2k commented Feb 11, 2026

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 11, 2026
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, enj

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

The pull request process is described here

Details Needs approval from an approver in each of these files:

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 k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 11, 2026
@k8s-ci-robot k8s-ci-robot merged commit ae8460b into kubernetes:master Feb 11, 2026
4 checks passed
@k8s-ci-robot k8s-ci-robot added this to the v1.36 milestone Feb 11, 2026
@github-project-automation github-project-automation bot moved this from Needs Triage to Closed / Done in SIG Auth Feb 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/auth Categorizes an issue or PR as relevant to SIG Auth. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.

Projects

Status: Closed / Done

Development

Successfully merging this pull request may close these issues.

4 participants