Skip to content

PEP458: Bootstrap TUF metadata repository for development #15484

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Apr 5, 2024

Conversation

kairoaraujo
Copy link
Contributor

This PR is part 2 in a series of PRs to integrate Repository Service for TUF (RSTUF) with Warehouse for PEP 458 adoption.

Previous PR was #15241

This PR adds scripts, configuration and static metadata to bootstrap a PEP 458 - compliant TUF metadata repository for development.

This bootstrapping process also initializes the RSTUF API to accept API requests, and trigger the related TUF metadata updates.

Change details

  • Add RSTUF dev keys for offline and online signing
    These keys are for demo purposes only and must not (!) be used in production. In production we recommend hardware tokens for offline signing and Cloud KMS for online signing.

  • Configure RSTUF Worker to mount online signing key file 1

  • Add static RSTUF development bootstrap payload
    This payload contains bootstrapping configuration and the development root metadata. The latter defines two root keys and one online key (see above), and is pre-signed.

  • Add Makefile target to send the payload to the API, to trigger bootstrapping.

  • Add dev instructions on how to run init and how to interact with the API.

Next PRs will include:

  • Backsigning (generate TUF metadata for existing PyPI indices)
  • Integration with distribution file upload/removal
  • Introduction of metadata bootstrap/update cli for production

Thanks, @lukpueh, for helping with many parts of this PR.

Footnotes

  1. For the interested reader only: The RSTUF worker will locate the online signing key file by combining ambient configuration from the container environment (see "RSTUF_ONLINE_KEY_DIR") with the exact identifier included in the root metadata (see "x-rstuf-online-key-uri"). The same approach works, when using Cloud KMS, where e.g. access credentials are configured via environment variables, and the particular keyid with the public key in the delegating metadata.

@kairoaraujo kairoaraujo requested a review from a team as a code owner February 26, 2024 15:36
@trishankatdatadog
Copy link
Contributor

Amazing: never seen a PR enable code through pure config 👏🏽

Copy link
Contributor

@trishankatdatadog trishankatdatadog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM FWIW

@kairoaraujo
Copy link
Contributor Author

Hi @ewdurbin,
Following your suggestion to deliver chunks of this iteratively, I have the second PR for you here. ☺️
Let me know how I can improve it.

Copy link
Member

@ewdurbin ewdurbin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this is working as expected with two concerns:

  1. Seems there is some raciness that is causing the rstuff-worker to fail to boot due to the DB not existing, move parts of our db initialization into db service #15549 should address this.
  2. Both rstuf-api and rstuf-worker containers do not exit cleanly, and instead are killed after a 10s timeout. Is this expected?
Screenshot 2024-03-11 at 8 30 07 AM

@kairoaraujo
Copy link
Contributor Author

Overall this is working as expected with two concerns:

  1. Seems there is some raciness that is causing the rstuff-worker to fail to boot due to the DB not existing, move parts of our db initialization into db service #15549 should address this.

Thanks, @ewdurbin. It looks like an great solution.
Yes, that is why we tried to document to run make inittuf after make serve. But your solution is way better.

  1. Both rstuf-api and rstuf-worker containers do not exit cleanly, and instead are killed after a 10s timeout. Is this expected?

Indeed, these two containers take about 10s to stop, including in my development environment without a Warehouse.

Aborting on container exit...
[+] Stopping 5/5
 ✔ Container repository-service-tuf-worker-repository-service-tuf-worker-1  Stopped              10.2s 
 ✔ Container repository-service-tuf-worker-repository-service-tuf-api-1     Stopped              10.2s 
 ✔ Container repository-service-tuf-worker-redis-1                          Stopped               0.2s 
 ✔ Container repository-service-tuf-worker-postgres-1                       Stopped               0.2s 
 ✔ Container repository-service-tuf-worker-localstack-1                     Stopped               0.9s

I will file an issue on the RSTUF project to investigate if we can make it faster.

@kairoaraujo
Copy link
Contributor Author

Rebased

Kairo Araujo added 10 commits April 5, 2024 11:12
- RSTUF API v0.12.0b1
- RSTUF Worker v0.14.0b1

Signed-off-by: Kairo Araujo <[email protected]>
Include RSTUF keys to be used on development environment.

Include two root keys:
   root1: ecdsa format
   root2: ed25519 format

Include online key
2f685fa7546f1856b123223ab086b3def14c89d24eef18f49c32508c2f60e241 RSA

Signed-off-by: Kairo Araujo <[email protected]>
Signed-off-by: Lukas Puehringer <[email protected]>
Include in `docker-compose.yml` the configuration for using local
online key for development.

- Use local volume from `./dev/rstuf/keys/online` as `/keyvault`
- Use `/keyvault` as RSTUF Worker setting `RSTUF_ONLINE_KEY_DIR`

Signed-off-by: Kairo Araujo <[email protected]>
Include the RSTUF command line interface (`repository-service-tuf`).

This tool will be used in the development enviroment to perform tasks on
the RSTUF service.

This tool will be used primary for RSTUF bootstrap.

Signed-off-by: Kairo Araujo <[email protected]>
Include the RSTUF `bootstrap.json` payload in the `dev/rstuf/` folder.

The bootstrap payload has the RSTUF complete ceremony process.
It uses the keys available in the `dev/rstuf/keys`

This commit also includes the `inittuf` in Makefile.

The information in the development docs.
- context (PEP 458)
- command (bootstrap)
- use (try out API)

Signed-off-by: Kairo Araujo <[email protected]>
Signed-off-by: Lukas Puehringer <[email protected]>
It exposes the TUF metadata at `http://files:9001:tuf-metadata` in the
container network.
For developers at `http://localhost:9001/tuf-metadata`.

This commit includes the entry on `docker-compose.yml` and the
`rstuf-metadata` volume which is attached to the `files` container.

Signed-off-by: Kairo Araujo <[email protected]>
Fix formatting for `make server` mention in getting-started doc.

Signed-off-by: Kairo Araujo <[email protected]>
@kairoaraujo
Copy link
Contributor Author

I rebased the PR.
Let me know if I can help to move forward with this PR :)

@ewdurbin
Copy link
Member

ewdurbin commented Apr 5, 2024

Any progress on the slow stop? I think what's here is good to go but would really like to see that improved sooner than later.

@kairoaraujo
Copy link
Contributor Author

Any progress on the slow stop? I think what's here is good to go but would really like to see that improved sooner than later.

I filed the issue but haven't worked on it yet.
We have RSTUF sprint planning today, and I will add it to the next sprint.

@ewdurbin
Copy link
Member

ewdurbin commented Apr 5, 2024

Added 5f5282d for now, which gets them down by force.

@ewdurbin ewdurbin enabled auto-merge (squash) April 5, 2024 09:49
@ewdurbin ewdurbin merged commit 5ecfe11 into pypi:main Apr 5, 2024
lukpueh added a commit to kairoaraujo/warehouse that referenced this pull request Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants