add oc-elevate function

[T0MASD]

prompts for justification before commands as cluster admin

example when providing a justification:

[~ {production} (hive-xxx:default)]$ oc-elevate get pod -A -o json | jq -r '.items | length'
Enter justification for performed elevated action (60s timeout):test test
445

example when not providing a justification due to timeout or empty string

[~ {production} (hive-xxx::default)]$ oc-elevate get pod -A -o json | wc -l
Enter  justification for performed elevated action (60s timeout):
No justification for elevated action was given exiting...
0

Confirmed with security team, justification is sent to the audit log

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: T0MASD Once this PR has been reviewed and has the lgtm label, please assign iamkirkbater for approval. 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: - **[OWNERS](https://github.com/openshift/ocm-container/blob/master/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[clcollins]

This is awesome, and LGTM generally. Would you be opposed to the function taking an argument to add the REASON via a flag using bash's GETOPS (or something), to support just running it with a flag, or prompting if run without one?

Something like oc-elevate -r "This was my reason for elevating"?

[clcollins]

Oh, and one more idea - this is already named properly and would be an excellent candidate for an OC plugin - it just needs to go into /usr/local/bin instead of the bashrc.d utils, and execute the function automatically.

oc elevate get pod -A....

[iamkirkbater]

+1 to having a reason passed in and not have to provide it in a text prompt afterwards.

[iamkirkbater]

I also think that having the reason be mandatory and explicitly fail out if there's no reason provided would be a better option here. The whole point is to provide a reason why you're escalating so you don't get a compliance ticket, otherwise --as backplane-cluster-admin would be sufficient.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle rotten /remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci[bot]]

@openshift-bot: Closed this PR.

In response to [this](https://github.com/openshift/ocm-container/pull/199#issuecomment-1868139824): >Rotten issues close after 30d of inactivity. > >Reopen the issue by commenting `/reopen`. >Mark the issue as fresh by commenting `/remove-lifecycle rotten`. >Exclude this issue from closing again by commenting `/lifecycle frozen`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.