jschoubben
2096d0b2a1
Seven assertions against a real store, the important one being that a consumer cannot reach another consumer's bucket — isolation here is a policy somebody wrote rather than a boundary the product has. The revocation test stages its own precondition. The first version asserted a key left by an earlier test, and the rotation test had already revoked it two tests early: the behaviour was correct and the test was measuring residue. Its precondition assertion is what caught that, rather than it passing green having verified nothing.
32 lines
1.2 KiB
YAML
32 lines
1.2 KiB
YAML
# One machine running an object store that other machines use.
|
|
#
|
|
# The same shape as `a-provider`, against a different kind of provision, and that is the whole
|
|
# reason it exists: novox/hq 04-ISSUES and the work breakdown's Phase 1.1 ask whether a module can
|
|
# be given a bucket the way it is given a database. The provisioning model is name-agnostic — the
|
|
# control plane special-cases neither — so what is unproven is not the mesh's half but the last
|
|
# step, where something on the machine turns a delivered secret into a key that works.
|
|
#
|
|
# It also proves the half a database does not: **a consumer must not be able to reach another
|
|
# consumer's bucket.** One store holds everybody's, where one PostgreSQL server holds separate
|
|
# databases, so isolation here is a policy somebody wrote rather than a boundary the product has.
|
|
scenario: an-object-store
|
|
|
|
segments:
|
|
hosting:
|
|
kind: public
|
|
cidr: [192.0.2.0/24]
|
|
|
|
machines:
|
|
anchor:
|
|
at: { segment: hosting, address: [192.0.2.10] }
|
|
inbound: allow
|
|
|
|
images:
|
|
- minio/minio:RELEASE.2025-09-07T16-13-09Z
|
|
# The vendor's client, stocked so the provisioner has the thing it drives without reaching a
|
|
# public registry from a documentation range.
|
|
- minio/mc:RELEASE.2025-08-13T08-35-41Z
|
|
|
|
place:
|
|
all: [runtime]
|