CKA Mock exam 2 query

Kubernetes
#1

Hi Team,

I am not sure why the question mentioned below is marked as false in the Test results. Kindly assist. Thanks!

Q:
Create a new user called john. Grant him access to the cluster. John should have permission to create, list, get, update and delete pods in the development namespace . The private key exists in the location: /root/CKA/john.key and csr at /root/CKA/john.csr.

Important Note: As of kubernetes 1.19, the CertificateSigningRequest object expects a signerName.

Please refer to the documentation to see an example. The documentation tab is available at the top right of the terminal.

Answer :

  • YAML to create for CSR
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: john-developer
spec:
  request: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZEQ0NBVHdDQVFBd0R6RU5NQXNHQTFVRUF3d0VhbTlvYmpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRApnZ0VQQURDQ0FRb0NnZ0VCQUxJSmVtVERnMUdVSGZFdVlJd2NaWG9ZdEtNbmhuRWhHTE90Mnh2cEgzc3RTSkd2ClZJbFpvcmkxS0JOOEJBQWkzTzREQWp2eXV1VGpDS2dSY1RYN1lqbWlwR044OW5XMEE1MUVJdmZuMUk4UGFyQnQKUVRZZ0YxazFEbENyL1RiMmZGTkxob1Y5UU4yT0ZmTGp5djFtUURUWjhhWHd4VVBKUVRneUV6UEdhT3NJNEpiegpybEd0alI4Tlp5NTVLUHc1c0ZYQ1BOV1JkLzZLblFhYmFFeno2Yk1jeWlWd1I4SVlMbEhLN1dkcUlvbjEwUzNVCm1vWnU1ZjRmM1ZMR1Y3b0NwbzlQcEtHdDNoaVpseS9qT3FCOTdPZXYwTmJRUE9JQ1NXelRLUmJFMm5tMkxrOXQKcmZtdFdCci9UblRTTVBwSWxpRmpTL05tUHlBUkJac3hnNVNCRTI4Q0F3RUFBYUFBTUEwR0NTcUdTSWIzRFFFQgpDd1VBQTRJQkFRQi8vN2ljUXo1WlRESWovQzZXOEdlbUcrdTZVWnZrMnlnVkxrbGtsM3BmYmtHQ1lsZnFNSVZFCmtrOVd2SlduMGhTdkZmL2VaczBFU0VQVzBwVi81bHk2TTVlQlhYVnRtRU5ud0d5aTVMaStCQlI0ZDFGMUF5YXkKTHp4TFk1Yzh3VWVONXZjcjhITzRsN0NKOTVDV3hML2puME9OeEZ6MHBiVGFVcnpYa0hRc3p5VmZDVW5lek4vTgppTzNOanBQOC9HUng4ZWUwWDUwdCtGOER6Z3VRYUIvM1ZsL2hSc1JWTnNvOW4yTU1Cb1BPelpQOWxoRXhNemNsClBWNXc5YmVnNnFMeVgxUEJrcHI2WVVZbEFVdGpkcFdZN0VQWDUzTm1EQ1h1ZGlFdmQvbDVKbzN3dTFRNzAyYWoKUnd0WUFjNTExQmozdDR5RlhTZXhaSWJ1QVdsMllBb3oKLS0tLS1FTkQgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg=="
  signerName: "kubernetes.io/kube-apiserver-client"
  usages:
  - digital signature
  - key encipherment
  - server auth

-Approved the csr

cluster1-controlplane ~ âś– k get csr
NAME             AGE    SIGNERNAME                                    REQUESTOR                           REQUESTEDDURATION   CONDITION
csr-lc28p        114m   kubernetes.io/kube-apiserver-client-kubelet   system:node:cluster1-controlplane   <none>              Approved,Issued
csr-w7f56        113m   kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:ccullm             <none>              Approved,Issued
john-developer   66m    kubernetes.io/kube-apiserver-client           kubernetes-admin                    <none>              Approved,Failed
  • Yaml of the role created
cluster1-controlplane ~ âžś  k get role -n john-developer -n development   -o yaml 
apiVersion: v1
items:
- apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    creationTimestamp: "2025-04-17T04:50:20Z"
    name: developer
    namespace: development
    resourceVersion: "6673"
    uid: eca3c61f-f648-478c-8366-ec1706e6bbf2
  rules:
  - apiGroups:
    - ""
    resources:
    - pods
    verbs:
    - create
    - list
    - get
    - update
    - delete
kind: List
metadata:
  resourceVersion: ""

-Yaml of the rolebinding created

cluster1-controlplane ~ âžś  k get rolebindings.rbac.authorization.k8s.io  -n development   -o yaml 
apiVersion: v1
items:
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: "2025-04-17T04:52:18Z"
    name: john-developer
    namespace: development
    resourceVersion: "6913"
    uid: 0f509e1f-1efe-4fb0-b41b-a2562296436c
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: developer
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: john-developer
kind: List
metadata:
  resourceVersion: ""
  • Checking the permisiions
luster1-controlplane ~ âś– k auth can-i delete pods -n development --as john-developer
yes

cluster1-controlplane ~ âžś  k auth can-i get  pods -n development --as john-developer
yes

cluster1-controlplane ~ âžś  k auth can-i list  pods -n development --as john-developer
yes

cluster1-controlplane ~ âžś  k auth can-create  pods -n development --as john-developer
error: unknown command "can-create pods"
See 'kubectl auth -h' for help and examples

cluster1-controlplane ~ âś– k auth can-i create  pods -n development --as john-developer
yes

I think you should provide more time to review lab results, 15 min is too less.

Thanks,
Sakshi

#2

Is this question from in-course CKA Mock 2?

The issue here is with the name in the RoleBinding.subjects. It should refer to the user’s name as available in the certificate — john, in this case. The name you have provided is the name of the CSR, and it doesn’t affect the permissions. The Common Name (CN) in an x509 CSR is what the user’s name will be in the cluster.

There’s a detailed explanation on this here.

Once the RoleBinding is updated, you can validate with:

k auth can-i get pods -n development --as jonh   # Notice the change in name

# john should not be able to get pods in default ns
k auth can-i get pods --as john
# This should return no
#3

alright, so I have an issue with the wording of this specific question. I don’t know how to have that addressed. Truth be told, I don’t even know if the way it is worded is correct (I mean, is it meant to be intentionally confusing? lol).

The question provides us with a certificate john.csr. It asks us to create a john-developer CertificateSigningRequest object (please note the name john-developer…lol). Then it goes on to create access for “john” not “john-developer”.

Now, I COMPLETELY understand that this is possible but what is the purpose of the creation of the “john-developer” CertificateSigningRequest?

I’ll tell you what I did. Following chronologically, I had created a john-developer CertificateSigningRequest object and gotten it approved. Then, seeing that the question was checking for a “john” user, I went back deleted the csr, recreated the CertificateSigningRequest object for “john”.

Ultimately, I failed it. (rofl)

I wish to submit for a review of that question and how it may come across as confusing to some of us. (or in the answer provided, please explain the reasoning) because in our “real-life” jobs, we might thing that is the norm.

and even after going through the correction steps suggested, I still got the question wrong (despite being able to perform successfully, the verification that was suggested by the provided answer):

cluster1-controlplane ~ âžś kubectl auth can-i update pods --as=john --namespace=development
yes

Unfortunately, I ran out of time on the lab before I could provide all of my definition files. But I perfectly understand why @sakshibag80 was binding with “john-developer” instead o just “john”.

@Santosh_KodeKloud please would you know (or be able to find out if there is) any explanation for this?

#4

Hi @Santosh_KodeKloud

Thanks for getting back.

The issue here is with the name in the RoleBinding.subjects . It should refer to the user’s name as available in the certificate — john , in this case. The name you have provided is the name of the CSR, and it doesn’t affect the permissions. The Common Name (CN) in an x509 CSR is what the user’s name will be in the cluster.

Even if you create a CSR with the username John, the question still fails. This question needs to be reviewed and corrected.

I am also NOT very sure why the status of CSR for John is "Approved and Failed "

luster1-controlplane ~ âžś  k get csr
NAME        AGE   SIGNERNAME                                    REQUESTOR                           REQUESTEDDURATION   CONDITION
csr-8dp4f   94m   kubernetes.io/kube-apiserver-client-kubelet   system:node:cluster1-controlplane   <none>              Approved,Issued
csr-d42cb   93m   kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:f9rvvv             <none>              Approved,Issued
john        24s   kubernetes.io/kube-apiserver-client           kubernetes-admin                    <none>              Approved,Failed

Kindly share your thoughts.

Thanks,
Sakshi

#5

@sakshibag80

I think you got it wrong.

The CSR (CertificateSigningRequest) object and the subject field in a RoleBinding serve two distinct purposes and are not directly connected by name. The CSR named john-developer is simply the name of a Kubernetes resource — much like the name of a Pod or Service. This name is used to identify and manage the CSR object itself within Kubernetes, but it does not define the user identity.
The actual user identity that Kubernetes recognizes comes from the Common Name (CN) field inside the certificate that is generated after the CSR is approved.

When you create a RoleBinding, the subjects field expects the username that matches the CN in the certificate, not the CSR’s Kubernetes object name. For example, if John’s certificate has CN=john, then the RoleBinding’s subject should specify name: john.

I recommend reviewing the blog I linked earlier for a detailed explanation. Also, try inspecting John’s certificate to see the CN field and understand what username Kubernetes will recognize.

Your CSR should be named john-developer and your RoleBinding should refer to user john in its subject field.

1 Like
#6

@sakshibag80
Please read this document to understand the relationship between users and signing requests. The following is crucial to understand

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: john-developer  # <-- NOT necessarily the user's name!!!!!
1 Like
#7

Hi @Santosh_KodeKloud,

Thanks for getting back.

Does this mean every time a csr is provided, we need to review the user name in the CN name of the CSR first and then use that in the rolebinding object?

Regards,
Sakshi

#8

I would recommend that you memorize the openssl command for examining a .csr file, so you can be exactly sure what the cluster user’s name will be

openssl is a very useful command for working with certificates and signing requests to view what is inside them, and it is pretty much installed by default on most Linux distros. Absolutely it is present on exam environments. What should be known for CKA is

openssl <command> -in <file> -noout -text

where

<command> is one of

  • req - for certificate signing requests
  • x509 - for normal certificates (like those in /etc/kubernetes/pki). You would use this form if you needed to know for instance the expiry date of a certificate.

<file> is the file (.csr or .crt) you want to run <command> on.

#9

Thank you both (@Alistair_KodeKloud and @Santosh_KodeKloud for taking time to respond to this.

After going through the github page, it made a lot more sense. I guess the question is good to reinforce the fact that CSR object name is not necessarily the user’s name. lol.