test

const (
	// KongSystemServiceCert is a testing TLS certificate with SAN *.kong-system.svc.
	//
	// created with:
	//
	// openssl req \
	//   -x509 \
	//   -newkey rsa:4096 \
	//   -sha256 \
	//   -days 3560 \
	//   -nodes \
	//   -keyout tls.key \
	//   -out tls.crt \
	//   -subj '/CN=*.kong-system.svc' \
	//   -extensions san \
	//   -config <( \
	//     echo '[req]'; \
	//     echo 'distinguished_name=req'; \
	//     echo '[san]'; \
	//     echo 'subjectAltName=DNS:*.kong-system.svc')
	KongSystemServiceCert = `` /* 1760-byte string literal not displayed */

	// KongSystemServiceKey is the private key for the testing certificate kongSystemServiceCert.
	KongSystemServiceKey = `` /* 3271-byte string literal not displayed */

)

const (
	// XXX (this hack is tracked in https://github.com/Kong/kubernetes-ingress-controller/issues/1613):
	//
	// The test process (`go test github.com/Kong/kubernetes-ingress-controller/test/integration/...`) serves the webhook
	// endpoints to be consumed by the apiserver (so that the tests can apply a ValidatingWebhookConfiguration and test
	// those validations).
	// In order to make that possible, we needed to allow the apiserver (that gets spun up by the test harness) to access
	// the system under test (which runs as a part of the `go test` process).
	// In the constants below, we're making an audacious assumption that the host running the `go test` process is also
	// the Docker host on the default bridge (therefore it can listen on 172.17.0.1), and that the apiserver
	// is running within a context (such as KIND running on that same docker bridge), from which 172.17.0.1 is routable.
	// This works if the test runs against a KIND cluster, and does not work against cloud providers (like GKE).
	AdmissionWebhookListenHost = "172.17.0.1"
	AdmissionWebhookListenPort = 49023
)