Remove apf_fd from httplog

[jupblb]

What type of PR is this?

/kind bug

What this PR does / why we need it:

Since flowDistinguisher may hold data identifying a user accessing the cluster this can be a source of a PII leak. We should remove this from the httplog for now until a better solution can be found.

Which issue(s) this PR fixes:

N/A

Special notes for your reviewer:

The code responsible for logging this information was added in: #104359 /cc @mborsz

Does this PR introduce a user-facing change?

Fixes a 1.23 regression in kube-apiserver: removed apf_fd from server logs which could contain data identifying the requesting user

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[wojtek-t]

Thanks - yes, I think it's necessary as we don't want leaking PII in logs.

But I want to give others time to react.
@MikeSpreitzer @tkashem @deads2k

[wojtek-t]

/cc @MikeSpreitzer @tkashem @deads2k

[jupblb]

/retest

[liggitt]

We should remove this from the httplog for now...

Agreed

...until a better solution can be found.

is the flow distinguisher always derivable from the FlowSchema? if so, we already log the flow schema, so don't really need the flow distinguisher, right?

[liggitt]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jupblb, liggitt

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:

• staging/src/k8s.io/apiserver/OWNERS [liggitt]

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

[wojtek-t]

is the flow distinguisher always derivable from the FlowSchema? if so, we already log the flow schema, so don't really need the flow distinguisher, right?

It's not - it's a hash of proper field from the object (more-or-less) - we have two methods:

• by user
• by namespace
  [So those are effectively computed from the corresponding fields]:
  https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/flowcontrol/v1beta2/types.go#L170-L182

[liggitt]

sorry, I skipped my inner dialogue... I was thinking it would be useful to know the flow distinguisher type (user or namespace), so we could consider logging just that

that led to my question about whether the flow distinguisher type was always 1:1 with the flow schema, which we're already logging

[wojtek-t]

that led to my question about whether the flow distinguisher type was always 1:1 with the flow schema, which we're already logging

Yes - that is 1:1 with schema, so we know that (assuming that we know the current state of FS, which isn't obvious if we're debugging past state).

[liggitt]

assuming that we know the current state of FS, which isn't obvious if we're debugging past state

that's a good point. if we want to reintroduce the distinguisher type in logging in a follow-up, that might be useful

[fedebongio]

/triage accepted