✨ Add command for fetching permission claims

[varshaprasad96]

Summary

This PR adds command to get permission claims related to an APIBinding.
Example:

➜  kcp git:(cmd/permission-claim-get) ✗ kubectl-kcp claims get apibinding cert-manager
NAME                       BINDING            STATUS
group1-resource1    cert-manager   Rejected
group2-resource2   cert-manager   Rejected

➜  kcp git:(cmd/permission-claim-get) ✗ kubectl-kcp claims get apibinding
NAME                       BINDING            STATUS
group1-resource1    cert-manager   Rejected
group2-resource2   cert-manager   Rejected
group3-resource3   solo                   Accepted

Related design doc: https://docs.google.com/document/d/1J31wXY1-2aCyyGFjUlusKoHDzV-zktAmRdIMjMf4OR0/edit

[stevekuznetsov]

Do we have some example output?

[stevekuznetsov]

Will we support an -o json or --quiet? Can I pipe the output of this command into another command that accepts the claims?

[varshaprasad96]

Currently no. kubectl get accepts K8s objects itself as args. For example, having the output schema of pod or deployment would add value. We don't have an independent custom resource named permission claims.
Instead edit will reopen the entire APIBinding resource in an editor and allow users edit it. So there is no specific use case of piping the output to any other command directly and modifying the status of permission claim.

[varshaprasad96]

@stevekuznetsov a super basic sample output is in the PR description (github is screwing up the formatting). It is basically the output of whatever I am specifying in apibinding.spec.permisisonclaims

NAME                        BINDING             STATUS
corev1-configmap    cert-manager    Rejected
corev1-secret           cert-manager     Rejected

[fgiloux]

@stevekuznetsov a super basic sample output is in the PR description (github is screwing up the formatting). It is basically the output of whatever I am specifying in apibinding.spec.permisisonclaims

NAME                        BINDING             STATUS
corev1-configmap    cert-manager    Rejected
corev1-secret           cert-manager     Rejected

Hi @varshaprasad96, how will it look like when name/namespace or selectors have been defined? Will they get added to the first column? What about verbs and subresources that may come later on? Will the verbs be in an additional column? It should not prevent this PR to get progressed but it may be interesting to have in mind what will come next.
What about naming the first column RESOURCES or CLAIMS if verbs were to be added to it later on? My feeling is that NAME does not carry much information.

[stevekuznetsov]

Yep - would love to have the leading column be the APIBinding name, and then have a column for group/version, and another for resource(s)

[varshaprasad96]

@fgiloux @stevekuznetsov Have modified the first column to be the APIBINDING name and the second to be RESOURCE GROUP-VERSION. We haven't decided on what the UI would like when additional fields like verbs/subresources/namespaces are added. We could either have them here by adding another column in future, or probably have just the sub resources included here and verbs in a metadata/additional-details column.

[stevekuznetsov]

IIRC we're about to make resource:group not 1:1 in permission claims but when that happens they can fiddle with the columns here.

[stevekuznetsov]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: stevekuznetsov

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:

• cmd/OWNERS [stevekuznetsov]
• pkg/cliplugins/OWNERS [stevekuznetsov]

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