Secure the Shipment Integration

Introduction

A shipment integration reads pending orders and publishes shipment updates. Its current repository example looks clean, but a removed API key may still grant access. You are responsible for containing that exposure and restoring the pending dispatch run.

Apply the Git investigation, targeted revocation, scope selection, private configuration, and business verification practiced in the guided labs. Complete the shipment result while preserving the unrelated monitor. The challenge starts in its own prepared environment.

Recover the Shipment Integration

Current Situation

The dispatch team uses a prepared worker to read pending orders and publish shipment updates. For example, order O-201 should receive state ready after the batch is processed. A key was removed from the current repository example, but an alert indicates it remains recoverable in history. The dispatch batch is pending. An unrelated availability monitor must keep working; a temporary pause in dispatch is acceptable during containment.

The environment uses the same local training provider, Git methods, manager UI, INI format, and two terminal roles as the guided labs. It is synthetic and does not require an external account.

Use the credentials from this VM, not a previous lab. As in the guided labs, this provider uses 401 for an invalid or revoked key, 403 for a valid key without the required scope, and 200 for an accepted read. The worker reads the private file on every invocation; it does not require a restart.

Scope

• Workstation opens in /home/labex/project/repository. Its three commits and shipping-example.ini contain the historical evidence. The current example is not the runtime configuration.
• Integration runs as keyworker in /home/labex/project. The private configuration is runtime/job.ini; the unchanged worker is /opt/keylab/worker.py, accepting a batch name as its argument.
• The API is http://127.0.0.1:8000. Key Manager administers credentials using the operator token in /home/labex/.config/keylab/operator-token.
• The independent monitor uses lab_key_monitor_only with GET /v1/health.

Your Goal

The historically exposed credential no longer grants API access. The unchanged shipment worker uses a distinct, dedicated replacement in its private runtime configuration, and the receiving service contains the complete dispatch shipment result under that replacement. Customer-directory access remains unavailable to the replacement, and the unrelated monitor remains healthy.

Acceptance Criteria

• The historical leaked key is revoked and gets 401 for order access while the API remains reachable.
• The configured replacement is active and has exactly the two shipment business scopes. It is distinct from the leaked key.
• /home/labex/project/runtime/job.ini belongs to keyworker, has mode 600, and is readable by that service account. The new secret occurs in neither repository files nor its commits.
• The unchanged worker has read the assigned dispatch batch under the configured replacement and the receiving API has accepted both orders, O-201 and O-202, each with state ready, under the same replacement ID.
• The replacement receives 403 for customer-directory access. The unchanged monitor credential still receives 200 from the health endpoint.

Hints

Summary

You transferred incident response from a support summary job to a shipment integration. A complete response invalidates the historical secret, restores the real business operation under a dedicated restricted credential, keeps secrets outside version control, and preserves unrelated service access.