Create Bucket-Limited Tokens for Each S3-Backed Volume Mount #28

New Issue

Open

opened 2023-08-21 15:07:20 +02:00 by so-rose · 0 comments

so-rose commented

2023-08-21 15:07:20 +02:00

Owner

We already create a dedicated S3 bucket each time an S3-backed volume is requested. However, currently, for simplicity, they all share one read-write token set which works for all buckets.

Not just each bucket, but each host's mount of each bucket, really ought to have its own dedicated token as well. For example, a host using a readonly-mounted rclone filesystem should only be given a read-only token set (ex. a #14 scheme), but the one host that needs the read-write rclone filesystem should instead be given a read-write token set.

Realizing this requires #24 to be tenable:

Per-host token set generation should be done via the Cloudflare API, whenever an appropriate token/host set doesn't yet exist, in deploy_volume_s3.
These tokens should be written to password-store (again, when they don't yet exist, or are expired) as a hot-path config, as described in #24.

We already create a dedicated S3 bucket each time an S3-backed volume is requested. However, currently, for simplicity, they all share one read-write token set which works for all buckets. Not just each bucket, but each host's mount of each bucket, really ought to have its own dedicated token as well. For example, a host using a `readonly`-mounted `rclone` filesystem should only be given a read-only token set (ex. a #14 scheme), but the one host that needs the read-write `rclone` filesystem should instead be given a read-write token set. Realizing this **requires** #24 to be tenable: - [ ] Per-host token set generation should be done via the Cloudflare API, whenever an appropriate token/host set doesn't yet exist, in `deploy_volume_s3`. - [ ] These tokens should be written to `password-store` (again, when they don't yet exist, or are expired) as a hot-path config, as described in #24.