Azure / Azure/osdu-spi

Deploy lane: mint the no-access identity token and give the resolver a source for it

Closed
#182 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Dockerfile
Stars
1
Forks
9
Avg merge
9h 23m
Merged PRs (30d)
58

Description

### Problem

The entitlements acceptance suite cannot run in the lane. Its Prove step fails at resolve ([run 34559415383](https://github.com/danielscholl-osdu/entitlements/actions/runs/34559415383)):

```
error: ENV_NOT_READY: unresolved required bindings: NO_ACCESS_USER_TOKEN
```

Every acceptance suite built on `os-core-test` reads `_TOKEN` for each user type it declares in `required-roles.json`. Entitlements declares `PRIVILEGED_USER` and `NO_ACCESS_USER`. Storage, search, and the other services with negative-path tests will declare the same two.

### Cause

The lane mints one bearer, as the deploy identity, and passes it as `RESOLVER_TOKEN` (`validate.yml`, "Mint test caller"). `resolve.py` has one `token` source that reads only that variable. There is no way for a descriptor to ask for the no-access identity's bearer, even though the stack mints it (`spi token --no-access`) and `spi onboard` already writes a federated credential for the fork on the no-access identity.

### Required change

1. Add a `noAccessToken` source to the resolver, read from `RESOLVER_NO_ACCESS_TOKEN`, with the same rules as `token`: no `default`, no `value`, empty counts as unset.
2. In "Mint test caller", log in as the no-access identity with `deploy_identity.no_access_client_id` from the facts and mint a second bearer for the same audience, masked and exported as `RESOLVER_NO_ACCESS_TOKEN`. The login must not replace the deploy identity's session, since Borrow and Restore run after it.
3. Extend the schema, the resolver README, the service descriptor runbook, and ADR-040's source table.
4. Update the entitlements descriptor example once the source exists: `NO_ACCESS_USER_TOKEN: { source: noAccessToken }`.

The stack side of this, making the no-access identity a member of `users` and the service user groups so it matches what `os-core-test` calls `NO_ACCESS_USER`, is tracked on osdu-spi-stack.

Contributor guide

Open the contributing guide

Research direction

Start with resolve.py and the existing token source, then trace the "Mint test caller" step in validate.yml and the referenced deploy_identity facts. Review the schema, resolver README, service descriptor runbook, ADR-040 source table, and entitlements descriptor example. Done means the no-access source resolves from its masked lane variable without replacing the deploy session, and the acceptance suite can resolve NO_ACCESS_USER_TOKEN.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, python
Domain
ci-cd, devops, testing
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.