:sparkles: Add interactive cmd prompt for permission claims

[varshaprasad96]

Summary

This PR introduces an interactive command prompt to edit the status of open claims for apibindings. The user can provide - Yes/No/Skip to accept/reject/skip any action on a permission claim respectively.

Use cases:

1. Edit permission claims related to a specific APIBinding:

➜  kcp git:(claims/edit) ./bin/kubectl-kcp claims edit apibinding cert-manager
Running interactive prompt. Enter (Yes/No/Skip)
Accept permission claim for Resource: secrets (APIBinding: cert-manager) > yes

2. Edit permission claims related to all apibindings in a workspace:

➜  kcp git:(claims/edit) ✗ ./bin/kubectl-kcp claims edit apibinding
Running interactive prompt. Enter (Yes/No/Skip)
No open claims found for apibinding: "apiresource.kcp.dev-1wked"
Accept permission claim for Resource: secrets (APIBinding: cert-manager) > Yes
No open claims found for apibinding: "tenancy.kcp.dev-59phz"

3. Use the edit command, but there are no open permission claims:

➜  kcp git:(claims/edit) ✗ ./bin/kubectl-kcp claims edit apibinding
Running interactive prompt. Enter (Yes/No/Skip)
No open claims found for apibinding: "apiresource.kcp.dev-1wked"
No open claims found for apibinding: "cert-manager"

What happens after editing?

• The APIBinding's spec.AcceptablePermssionClaim gets updated based on the user input. For example:

➜  kcp git:(claims/edit) ✗ k get apibinding cert-manager -o yaml
apiVersion: apis.kcp.dev/v1alpha1
kind: APIBinding
metadata:
  ...
spec:
  permissionClaims:
  - all: true
    resource: secrets
    state: Accepted
  reference:
    workspace:
      exportName: cert-manager-stable
      path: root:cert-manager-service
status:
  appliedPermissionClaims:
  - all: true
    resource: secrets
  boundResources:
  - group: cert-manager.io
    resource: certificaterequests
    schema:
...

PS: With the updates added to the permission claims spec (like sub-resources, verbs), the prompt's UI will need to change accordingly.

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

Related issue(s)

Fixes #

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign ncdc for approval by writing /assign @ncdc in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• contrib/OWNERS
• pkg/cliplugins/OWNERS

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

[nrb]

A question I don't see addressed in the design doc - will there be a way for users to programmatically accept permission claims? I know there's danger there and we might not want to make it too easy, but I'm anticipating someone asking.

[varshaprasad96]

A question I don't see addressed in the design doc - will there be a way for users to programmatically accept permission claims? I know there's danger there and we might not want to make it too easy, but I'm anticipating someone asking.

Agreed, for now my understanding was anyone who can access the workspace where APIBinding was created can change the state of the claim. Or maybe the right wording is, any user who can edit the apibinding can accept/reject respective claim. Are we looking to add another layer of rbac, wherein a user can view the binding, edit the export reference but not permission claim? (more like claims can be modified only be admins?)

[nrb]

Agreed, for now my understanding was anyone who can access the workspace where APIBinding was created can change the state of the claim. Or maybe the right wording is, any user who can edit the apibinding can accept/reject respective claim.

That's probably sufficient; if someone wants to automate things, they can use Go or wrappers around kubectl to do it. This command can be purely interactive. 👍

[openshift-merge-robot]

@varshaprasad96: PR needs rebase.

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.

[ncdc]

@varshaprasad96 so sorry for losing sight of this PR! Are you still available to work on it, or would you be interested in trying to find someone to take it over for you?

[varshaprasad96]

@ncdc I can work on this sometime this week and rebase with the latest changes.

[kcp-ci-bot]

Issues go stale after 90d of inactivity. After a furter 30 days, they will turn rotten. Mark the issue as fresh with /remove-lifecycle stale.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[sttts]

I still think we want this / something like this.

/remove-lifecycle stale

[kcp-ci-bot]

Issues go stale after 90d of inactivity. After a furter 30 days, they will turn rotten. Mark the issue as fresh with /remove-lifecycle stale.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kcp-ci-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[kcp-ci-bot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

[kcp-ci-bot]

@kcp-ci-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/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/test-infra repository.