This fixes the k3s entrypoint script in the docker compose integration
tests to ensure k3s runs as pid 1. This is required when running k3s in
docker if the host is using cgroup2.
Commit 08c186a contains a bug in the integration configuration template,
preventing the multi-stateless cluster from actually setting the
DEBUG_FORCE_AUTHENTICATE_FLOW environment variable. As a result this
cluster was not exercising the stateless authentication flow.
Fix the template so that this variable is applied as intended.
Add an integration test case to verify that the intended authentication
flow is in use: for the stateful flow, different routes should share the
same underlying session, but for the stateless flow, different routes
should receive different sessions.
Add an environment variable to allow forcing either the stateful or the
stateless authenticate flow.
Split the existing integration test clusters "single" and "multi" into
four new clusters: "single-stateful", "single-stateless",
"multi-stateful", and "multi-stateless", so that the integration tests
will run for both the stateful and the stateless authenticate flows.
(The "kubernetes" cluster is not currently being run, so I've left it
alone for now.)
An unused Redis TCP route was removed from the integration test
configuration template in commit bcddbff. Re-generate the test
configurations to incorporate this template change.
Several of the integration test certificates expired today. Update these
so that they are valid for another 10 years. Also update several other
certificates that were due to expire tomorrow.
Update the integration test libsonnet templates to assign a fixed IP
address to the trusted-httpdetails service. This requires also assigning
a fixed IP subnet to the docker network.
Configure a route with a 'to' URL using https and this fixed IP address.
Add a corresponding certificate with the IP address. Finally, add a test
case that makes a request to this route.
Move downstream mTLS settings to a nested config file object, under the
key 'downstream_mtls', and add a new DownstreamMTLSSettings struct for
these settings.
Deprecate the existing ClientCA and ClientCAFile fields in the Options
struct, but continue to honor them for now (log a warning if either is
populated).
Delete the ClientCRL and ClientCRLFile fields entirely (in current
releases these cannot be set without causing an Envoy error, so this
should not be a breaking change).
Update the Settings proto to mirror this nested structure.
Update the integration test templates to add a new client certificate
issued by downstream-ca-1, along with a combined CRL that revokes it.
(Setting a CRL just from downstream-ca-1 doesn't appear to work, which
surprises me.) Add a test case to verify that access is not allowed when
using the revoked certificate.
* integration test config: add downstream mTLS routes
Add two new CA certificates for use with downstream mTLS tests, and a
client certificate/key pair issued by each CA.
Add a few routes to the policy template that require a client CA. Update
the generated output configurations.
(based on commit ed63a6a6e7)
* add downstream mTLS integration test cases
These are modeled after the tests added to v0.17 in 83957a9, but here
the expected behavior is that requests with an invalid client
certificate will receive a 495 response only after authentication.
* integration: use postgres instead of redis for tests
* add missing environment variables for kubernetes
* fix certs
* use cert in generated files
* try new keys
* fix certs
* tls: fallback to self-signed certificate
* remove unknown domain because certs are no longer valid
* update multi-deployment to use service-specific certificates
