`kubectl auth can-i patch deployments/scale` says yes despite lacking permission to patch deployments/scale

[aibazhang]

What happened:

Even though I have not granted permission to patch deployments/scale to a user jane@example.com,
kubectl auth can-i -n demo patch deployments/scale --as=jane@example.com says yes.

What you expected to happen:

kubectl auth can-i patch deployments/scale should say no as expected.

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

Create a user Jane with CSR

openssl genrsa -out jane.key 2048
openssl req -new -key jane.key -out jane.csr -subj "/CN=jane@example.com/O=developers"
cat jane.csr | base64 | tr -d '\n'

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: jane
spec:
  request: <BASE64_ENCODED_CSR>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth

kubectl apply -f jane-csr.yaml
kubectl certificate approve jane
kubectl get csr jane -o jsonpath='{.status.certificate}' | base64 -d > jane.crt

Create a kubeconfig for Jane

kubectl config set-cluster <cluster-name> \
  --server=https://<api-server-url> \
  --certificate-authority=/path/to/ca.crt \
  --embed-certs=true \
  --kubeconfig=jane-kubeconfig

kubectl config set-credentials jane@example.com \
  --client-certificate=jane.crt \
  --client-key=jane.key \
  --embed-certs=true \
  --kubeconfig=jane-kubeconfig

kubectl config set-context jane@<cluster-name> \
  --cluster=<cluster-name> \
  --user=jane@example.com \
  --kubeconfig=jane-kubeconfig

Grant permissions with RABC

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: demo
rules:
# lacking permission to patch deployments/scale
  - apiGroups: ["autoscaling"]
    resources: ["horizontalpodautoscalers"]
    verbs: ["create", "update", "patch", "delete", "get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets", "daemonsets"]
    verbs: ["create", "update", "patch", "delete", "get", "list", "watch"]
  - apiGroups: ["policy"]
    resources: ["poddisruptionbudgets"]
    verbs: ["create", "update", "patch", "delete", "get", "list", "watch"]
  - apiGroups: [""]
    resources: ["services", "serviceaccounts", "configmaps", "pods", "pods/log", "pods/portforward", "pods/exec"]
    verbs: ["create", "update", "patch", "delete", "get", "list", "watch"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jane-developer
  namespace: demo
subjects:
- kind: User
  name: jane@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

kubectl auth can-i says yes.

$kubectl auth can-i -n demo patch deployments/scale --as=jane@example.com
yes
$kubectl auth can-i -n demo patch deployments/scale --kubeconfig=jane-kubeconfig
yes

However

$kubectl -n demo scale deployment --all --replicas=1 --kubeconfig=jane-kubeconfig
Error from server (Forbidden): deployments.apps "test-rbac" is forbidden: User "jane@example.com" cannot patch resource "deployments/scale" in API group "apps" in the namespace "demo"

After I added

  - apiGroups: ["apps"]
    resources: ["deployments/scale"]
    verbs: ["patch"]

to the developer role, kubectl -n demo scale deployment --all --replicas=1 --kubeconfig=jane-kubeconfig could be executed. kubectl auth can-i was misleading during our debug process.

Anything else we need to know?:

Environment:

• Kubernetes client and server versions (use kubectl version):
  • Client Version: v1.34.1
  • Kustomize Version: v5.7.1
  • Server Version: v1.33.0
• Cloud provider or hardware configuration: on-premise k8s cluster
• OS (e.g: cat /etc/os-release): macOS 15.6.1

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

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

[dhanishaphadate]

As per the cani.go code , the correct way to check for permission on subresources is

kubectl auth can-i -n demo patch deployments --subresource=scale

Before : Adding resources: ["deployments/scale"] to role developer I got

cluster1-controlplane ~$ kubectl auth can-i -n demo patch deployments --subresource=scale --as=jane@example.com 
no

After : Adding the scale subresource

cluster1-controlplane ~ $ kubectl get role developer -n demo -o yaml | grep -iC 6 deployments/scale
- apiGroups:
  - apps
  resources:
  - deployments
  - statefulsets
  - deployments/scale
  - daemonsets
  verbs:
  - create
  - update
  - patch
  - delete

cluster1-controlplane ~ $kubectl auth can-i -n demo patch deployments --subresource=scale --as=jane@example.com 
yes

There is also a example listed here

[dhanishaphadate]

/assign

[aibazhang]

Thank you!

As per the cani.go code , the correct way to check for permission on subresources is
kubectl auth can-i -n demo patch deployments --subresource=scale

I misunderstood the meaning of / here. deployments/scale means a deployment named "scale".

I'll close this issue.