chore: record pre-existing uncommitted repository state
Snapshot of the in-flight state that already existed, identically, in both this worktree and the main checkout before this session began: the initial HTTP Client platform implementation (previously untracked), the redis-lab removal, and the JPA / object-storage / notification integration work. Kept separate from this session's HTTP Client review response, which lands in the following commit, so the two bodies of work stay reviewable apart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
DongHyeonka
co-authored by
Claude Opus 5
Claude Opus 5
parent
1a3b560678
commit
5f10b791d3
@@ -0,0 +1,17 @@
|
||||
# ACL accounts
|
||||
|
||||
One file per `CommandAccess` level. Each account is deliberately narrower than the SDK's own rules:
|
||||
the account is the last enforcement boundary and a permit issued inside the process never widens it,
|
||||
so a mistake in the SDK is still refused by the server.
|
||||
|
||||
A Redis ACL file accepts nothing but complete `user` lines — no comments and no line continuations —
|
||||
which is why the rationale lives here instead of inline. Password material is supplied at deploy
|
||||
time; none of these files carries one.
|
||||
|
||||
| File | Account | Grants |
|
||||
| --- | --- | --- |
|
||||
| `application.acl` | `CommandAccess.APPLICATION` | the typed data-structure commands over `prod:*`, with the dangerous and deprecated names denied |
|
||||
| `application-advanced.acl` | `APPLICATION_ADVANCED` | the above plus pub/sub, transactions, and the registered-script path. `EVAL` is absent: only `EVALSHA` of an already loaded digest is reachable |
|
||||
| `raw-gateway.acl` | `RAW_GATEWAY` | exactly the commands the catalog classifies `RAW_ONLY`, and nothing else |
|
||||
| `all-accounts.acl` | – | the four accounts concatenated; Redis takes one `aclfile`, so this is what a deployment loads |
|
||||
| `admin-readonly.acl` | `ADMIN_READONLY` | read-only diagnostics. Every destructive counterpart is denied here and blocked in the command policy catalog — two independent controls for the same rule |
|
||||
@@ -0,0 +1 @@
|
||||
user ca-skeleton-admin-readonly on nopass ~* resetchannels -@all +info +dbsize +time +lastsave +memory|usage +memory|stats +slowlog|get +slowlog|len +latency|latest +latency|history +client|list +client|info +command|info +command|docs +command|count +command|getkeysandflags +config|get +acl|dryrun +acl|whoami +cluster|info +cluster|slots +cluster|shards +cluster|nodes +object|encoding +object|freq +object|idletime +pubsub|channels +pubsub|numsub +pubsub|shardchannels +xinfo|stream +xinfo|groups +xinfo|consumers +function|list +function|stats +cluster|keyslot
|
||||
@@ -0,0 +1 @@
|
||||
user ca-skeleton-application-advanced on nopass sanitize-payload ~prod:* resetchannels &prod:* -@all +@read +@write +@string +@hash +@list +@set +@sortedset +@bitmap +@hyperloglog +@geo +@stream +@pubsub +@transaction +evalsha +evalsha_ro +script|load +script|exists +fcall +fcall_ro -keys -flushdb -flushall -shutdown -debug -eval -eval_ro -smembers -sort -sort_ro -randomkey -migrate -swapdb -select
|
||||
@@ -0,0 +1 @@
|
||||
user ca-skeleton-application on nopass sanitize-payload ~prod:* resetchannels &prod:* -@all +@connection +@pubsub +@transaction +@read +@write +@string +@hash +@list +@set +@sortedset +@bitmap +@hyperloglog +@geo +@stream -keys -flushdb -flushall -shutdown -debug -sort -sort_ro -smembers -randomkey -migrate -swapdb -select
|
||||
@@ -0,0 +1 @@
|
||||
user ca-skeleton-raw-gateway on nopass sanitize-payload ~prod:* resetchannels -@all +smembers +sort +sort_ro
|
||||
@@ -0,0 +1,26 @@
|
||||
# Standalone lane for the Redis SDK topology tests.
|
||||
#
|
||||
# The version is a build argument rather than a pinned image so the same file serves every row of
|
||||
# the support matrix. Nothing here is a production topology: no persistence, no TLS, no replication.
|
||||
# It exists to answer "does the driver behave the way the SDK claims", which is a question the
|
||||
# in-memory fixture cannot answer at all.
|
||||
services:
|
||||
redis:
|
||||
image: "redis:${REDIS_VERSION:-7.4}"
|
||||
command:
|
||||
- redis-server
|
||||
- --appendonly
|
||||
- "no"
|
||||
- --save
|
||||
- ""
|
||||
- --aclfile
|
||||
- /etc/redis/acl/all-accounts.acl
|
||||
volumes:
|
||||
- ../acl:/etc/redis/acl:ro
|
||||
ports:
|
||||
- "${REDIS_PORT:-6379}:6379"
|
||||
healthcheck:
|
||||
test: ["CMD-SHELL", "[ \"$$(redis-cli --user ca-skeleton-application --pass fixture-application --no-auth-warning ping)\" = PONG ]"]
|
||||
interval: 2s
|
||||
timeout: 2s
|
||||
retries: 15
|
||||
@@ -0,0 +1,78 @@
|
||||
# TLS lane for the Redis SDK topology tests.
|
||||
#
|
||||
# Standalone in shape, but the point is the transport: the SDK's TLS settings — enabled, hostname
|
||||
# verification, trust material, client certificate — are configuration nothing else exercises, and
|
||||
# a TLS path that has never carried a command is a claim rather than a capability.
|
||||
#
|
||||
# The certificates are generated at start-up rather than checked in. A checked-in key is a secret in
|
||||
# the repository however loudly the file is named "test", and a lane that regenerates its own
|
||||
# material also proves the trust configuration actually matters: point the client at the wrong CA
|
||||
# and it fails, which is what the qualification has to show.
|
||||
services:
|
||||
certs:
|
||||
# The redis image carries no openssl, so certificate generation gets an image that does. The
|
||||
# alternative — checking the material in — puts a private key in the repository.
|
||||
image: alpine/openssl:latest
|
||||
user: root
|
||||
volumes:
|
||||
- tls:/tls
|
||||
entrypoint:
|
||||
- /bin/sh
|
||||
- -c
|
||||
- |
|
||||
set -e
|
||||
if [ -f /tls/redis.crt ]; then exit 0; fi
|
||||
openssl genrsa -out /tls/ca.key 2048
|
||||
openssl req -x509 -new -nodes -key /tls/ca.key -sha256 -days 1 \
|
||||
-subj "/CN=ca-skeleton-test-ca" -out /tls/ca.crt
|
||||
openssl genrsa -out /tls/redis.key 2048
|
||||
openssl req -new -key /tls/redis.key -subj "/CN=localhost" -out /tls/redis.csr
|
||||
printf 'subjectAltName=DNS:localhost,IP:127.0.0.1' > /tls/redis.ext
|
||||
openssl x509 -req -in /tls/redis.csr -CA /tls/ca.crt -CAkey /tls/ca.key \
|
||||
-CAcreateserial -out /tls/redis.crt -days 1 -sha256 -extfile /tls/redis.ext
|
||||
chmod 644 /tls/redis.key /tls/ca.key
|
||||
|
||||
redis:
|
||||
image: "redis:${REDIS_VERSION:-7.4}"
|
||||
depends_on:
|
||||
certs:
|
||||
condition: service_completed_successfully
|
||||
volumes:
|
||||
- ../acl:/etc/redis/acl:ro
|
||||
- tls:/tls:ro
|
||||
command:
|
||||
- redis-server
|
||||
# Plaintext is off entirely. A lane that accepts both proves nothing about the TLS path,
|
||||
# because a misconfigured client would quietly fall back and still pass.
|
||||
- --port
|
||||
- "0"
|
||||
- --tls-port
|
||||
- "6379"
|
||||
- --tls-cert-file
|
||||
- /tls/redis.crt
|
||||
- --tls-key-file
|
||||
- /tls/redis.key
|
||||
- --tls-ca-cert-file
|
||||
- /tls/ca.crt
|
||||
- --tls-auth-clients
|
||||
- "no"
|
||||
- --appendonly
|
||||
- "no"
|
||||
- --save
|
||||
- ""
|
||||
- --aclfile
|
||||
- /etc/redis/acl/all-accounts.acl
|
||||
ports:
|
||||
- "${REDIS_PORT:-6390}:6379"
|
||||
healthcheck:
|
||||
test:
|
||||
- CMD-SHELL
|
||||
- >-
|
||||
[ "$$(redis-cli --tls --cacert /tls/ca.crt
|
||||
--user ca-skeleton-application --pass fixture-application --no-auth-warning ping)" = PONG ]
|
||||
interval: 2s
|
||||
timeout: 3s
|
||||
retries: 20
|
||||
|
||||
volumes:
|
||||
tls:
|
||||
Reference in New Issue
Block a user