kubectl returns kind: ValidatingAdmissionPolicyList for empty list of policies

[ilia1243]

What happened?

There is a cosmetic inconsistency of kubectl get validatingadmissionpolicies -o yaml output for empty and non-empty list of validating admission policies.

If there are no policies:

apiVersion: v1
items:
- apiVersion: admissionregistration.k8s.io/v1
  kind: ValidatingAdmissionPolicyList
  metadata:
    resourceVersion: "3817"
kind: List
metadata:
  resourceVersion: ""

If there is at least one policy:

apiVersion: v1
items:
- apiVersion: admissionregistration.k8s.io/v1
  kind: ValidatingAdmissionPolicy
  ...
kind: List
metadata:
  resourceVersion: ""

What did you expect to happen?

If there are no validating admission policies, kubectl get validatingadmissionpolicies -o yaml is expected to output:

apiVersion: v1
items: []
kind: List
metadata:
  resourceVersion: ""

How can we reproduce it (as minimally and precisely as possible)?

Run kubectl get validatingadmissionpolicies -o yaml provided that there are no validating admission policies in the cluster.

Anything else we need to know?

No response

Kubernetes version

$ kubectl version
Client Version: v1.30.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.0

Cloud provider

bare-metal

OS version

# On Linux:
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
$ uname -a
Linux k8s-control-plane-1 5.15.0-50-generic kubernetes/kubernetes#56-Ubuntu SMP Tue Sep 20 13:23:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Install tools

kubeadm

Container runtime (CRI) and version (if applicable)

containerd=1.6.12-0ubuntu1~22.04.3

Related plugins (CNI, CSI, ...) and versions (if applicable)

Calico v3.27.0

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[neolit123]

/sig cli

[sftim]

/transfer kubectl

[xyz-li]

Please assign this to me.
I think this is a bug of apiserver
kubectl get --raw /apis/admissionregistration.k8s.io/v1/validatingadmissionpolicies
{ "kind": "ValidatingAdmissionPolicyList", "apiVersion": "admissionregistration.k8s.io/v1", "metadata": { "resourceVersion": "30603" } }
kubectl get --raw /api/v1/nodes | jq .

{ "kind": "NodeList", "apiVersion": "v1", "metadata": { "resourceVersion": "30721" }, "items": [] }

[xyz-li]

/assign

[sftim]

Could be 2 bugs, because kubectl shouldn't interpret a missing items as the parent JSON document.

[xyz-li]

This may be the cause. If there is no item fields, kubectl won't treat the response as a list.
https://github.com/kubernetes/kubernetes/blob/bae83009d36fc9729482404dddc3b03ab751f08e/staging/src/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured/unstructured.go#L54C1-L61C2

[ardaguclu]

I'm not sure it is a bug. But this seems to be coming from server side printing https://github.com/kubernetes/kubernetes/blob/d0e78ef70e954f0233cc2e917b7c85cb957d36cd/pkg/printers/internalversion/printers.go#L567-L583

[ardaguclu]

I think this list printing mechanism https://github.com/kubernetes/kubernetes/blob/d0e78ef70e954f0233cc2e917b7c85cb957d36cd/pkg/printers/internalversion/printers.go#L1731-L1741 in server side printing is identical with the other resource type's list printing.
I don't think there is any bug in here.

/close

[k8s-ci-robot]

@ardaguclu: Closing this issue.

In response to this:

I think this list printing mechanism https://github.com/kubernetes/kubernetes/blob/d0e78ef70e954f0233cc2e917b7c85cb957d36cd/pkg/printers/internalversion/printers.go#L1731-L1741 in server side printing is identical with the other resource type's list printing.
I don't think there is any bug in here.

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

[xyz-li]

I think this list printing mechanism https://github.com/kubernetes/kubernetes/blob/d0e78ef70e954f0233cc2e917b7c85cb957d36cd/pkg/printers/internalversion/printers.go#L1731-L1741 in server side printing is identical with the other resource type's list printing. I don't think there is any bug in here.

/close

@ardaguclu

Server side printing is OK.
But what happens if you get the YAML output of validatingadmissionpolicies?
When there is no validatingadmissionpolicie in the apiserver, the response kubectl miss the field "items" and the output is incorrect.
This is definitely a bug.

# kubectl get validatingadmissionpolicies -oyaml
apiVersion: v1
items:
- apiVersion: admissionregistration.k8s.io/v1
  kind: ValidatingAdmissionPolicyList
  metadata:
    resourceVersion: "39450"
kind: List
metadata:
  resourceVersion: ""

[ardaguclu]

Could you please check the other list types and if there is any mismatch between them?. If there is any, I agree with you that this is a bug.

[xyz-li]

#kubectl get no -oyaml
apiVersion: v1
items: []
kind: List
metadata:
  resourceVersion: ""

#kubectl get po -oyaml
apiVersion: v1
items: []
kind: List
metadata:
  resourceVersion: ""


#kubectl get secret -oyaml
apiVersion: v1
items: []
kind: List
metadata:
  resourceVersion: ""

[ardaguclu]

Thanks for the check.

/reopen

[k8s-ci-robot]

@ardaguclu: Reopened this issue.

In response to this:

Thanks for the check.

/reopen

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.