Merge remote-tracking branch 'origin/development' into feature/prod-hardening
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 10s
CI / integration (pull_request) Successful in 15s
CI / ui (pull_request) Successful in 1m4s
CI / conformance (pull_request) Successful in 9s
CI / gate (pull_request) Successful in 1s
CI / deploy (pull_request) Successful in 1m40s
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 10s
CI / integration (pull_request) Successful in 15s
CI / ui (pull_request) Successful in 1m4s
CI / conformance (pull_request) Successful in 9s
CI / gate (pull_request) Successful in 1s
CI / deploy (pull_request) Successful in 1m40s
This commit is contained in:
@@ -231,8 +231,8 @@ services:
|
||||
# in prod — the test contour arrives as one shared NAT address, so a ban there
|
||||
# would be self-inflicted (the honeypot still logs). The prod deploy forces it on
|
||||
# in env.sh (deploy/write-prod-env.sh), not via a Gitea variable. GATEWAY_HONEYTOKEN
|
||||
# is the planted bearer trap; it is currently unset on every contour (no Gitea entry
|
||||
# feeds it), so the trap is inert until an operator wires a secret.
|
||||
# is the planted bearer trap, fed from the per-contour TEST_/PROD_GATEWAY_HONEYTOKEN
|
||||
# secret; empty (unset secret) leaves the trap off.
|
||||
GATEWAY_ABUSE_BAN_ENABLED: ${GATEWAY_ABUSE_BAN_ENABLED:-false}
|
||||
GATEWAY_HONEYTOKEN: ${GATEWAY_HONEYTOKEN:-}
|
||||
GATEWAY_LOG_LEVEL: ${LOG_LEVEL:-info}
|
||||
|
||||
Reference in New Issue
Block a user