Prototype CLI App for Rake Task Execution

[samsimpson1]

User Need

As a GOV.UK developer
I want a user-friendly approach to running Rake tasks
so that I can continue doing so without pod shell access

---

Context

(Add any extra context, links, diagrams, stakeholder interviews, etc.)

Shell access alternatives document

https://github.com/alphagov/govuk-platform-internal/issues/99

---

What’s Needed

List anything the solution must do or be (behaviour, performance, security, UX, etc.).

• Build a proof-of-concept CLI app for creating job execution requests and approvals

---

Acceptance Criteria

Clear, measurable conditions to verify the story is complete and valuable.

• A proof-of-concept for a Rake task execution workflow has been created
• Approval is required for creating, modifying or deleting workflows or executions
• Workflow creation, modification and execution actions taken by users are logged
• PoC has been demonstrated to users and stakeholders at Tech Fortnightly
• Broad Kubernetes permissions are not required to use the workflow

---

User Comms Plan (if applicable)

Briefly describe how you’ll let users know about the change.

Demo the workflow at Tech Fortnightly

[dj-maisy]

Question: Is this something we bake into the GDS-CLI?

[samsimpson1]

PoC has been created in Go and demoed at Tech Fortnightly.

It consists of:

• a CRD called JobRequest
• a piece of server software that runs in the cluster
• a validating webhook that validate the resources being created/updated (to ensure the requester != approver)
• a mutating webhook which sets the approver and creator fields based on K8s identity, to stop the forging of approver/creator fields
• a kubectl plugin which allows users to create and approve JobRequests

The workflow is:

1. The requesting user runs kubectl job-request create <image> <command>. The requesting user is provided with an approval command.
2. The requesting user sends the approval command to a colleague
3. The approving user runs the command, which outputs who requested the job run and the details of the job
4. The approving user approves the request
5. The Job is instantly created from the JobRequest