func (s *shutdownmanagerContext) healthzHandler(w http.ResponseWriter, r *http.R // file to understand if it is safe to terminate. The file-based approach is used since the process in which // the kubelet calls the shutdown command is different than the HTTP request from Envoy to /shutdown func (s *shutdownmanagerContext) shutdownReadyHandler(w http.ResponseWriter, r *http.Request) {+	// For testing, the filepath and check period can be overridden in the context+	// Otherwise, use the module constants+	var signalFilepath string+	if s.shutdownReadyFile != "" {+		signalFilepath = s.shutdownReadyFile+	} else {+		signalFilepath = shutdownReadyFile+	}+	var signalFileCheckDuration time.Duration+	if s.shutdownReadyCheckInterval != 0 {+		signalFileCheckDuration = s.shutdownReadyCheckInterval+	} else {+		signalFileCheckDuration = shutdownReadyCheckInterval+	}++	l := s.WithField("context", "shutdownReadyHandler")+	ctx := r.Context() 	for {-		_, err := os.Stat(shutdownReadyFile)-		if err != nil {+		_, err := os.Stat(signalFilepath)+		if err == nil {

 const (  // File path used in the /shutdown endpoint. const shutdownReadyFile = "/ok"+const shutdownReadyCheckInterval = time.Second * 1

 func (s *shutdownmanagerContext) healthzHandler(w http.ResponseWriter, r *http.R // file to understand if it is safe to terminate. The file-based approach is used since the process in which // the kubelet calls the shutdown command is different than the HTTP request from Envoy to /shutdown func (s *shutdownmanagerContext) shutdownReadyHandler(w http.ResponseWriter, r *http.Request) {+	// For testing, the filepath and check period can be overridden in the context+	// Otherwise, use the module constants+	var signalFilepath string+	if s.shutdownReadyFile != "" {+		signalFilepath = s.shutdownReadyFile+	} else {+		signalFilepath = shutdownReadyFile+	}+	var signalFileCheckDuration time.Duration+	if s.shutdownReadyCheckInterval != 0 {+		signalFileCheckDuration = s.shutdownReadyCheckInterval+	} else {+		signalFileCheckDuration = shutdownReadyCheckInterval+	}

 func (s *shutdownmanagerContext) healthzHandler(w http.ResponseWriter, r *http.R // the kubelet calls the shutdown command is different than the HTTP request from Envoy to /shutdown func (s *shutdownmanagerContext) shutdownReadyHandler(w http.ResponseWriter, r *http.Request) { 	for {-		if _, err := os.Stat(shutdownReadyFile); err == nil {+		_, err := os.Stat(shutdownReadyFile)+		if err != nil { 			http.StatusText(http.StatusOK) 			if _, err := w.Write([]byte("OK")); err != nil { 				s.WithField("context", "shutdownReadyHandler").Error(err) 			} 			return-		} else {-			s.WithField("context", "shutdownReadyHandler").Errorf("error checking for file: %v", err) 		}+		s.WithField("context", "shutdownReadyHandler").Errorf("error checking for file: %v", err)

 func (s *shutdownmanagerContext) healthzHandler(w http.ResponseWriter, r *http.R // file to understand if it is safe to terminate. The file-based approach is used since the process in which // the kubelet calls the shutdown command is different than the HTTP request from Envoy to /shutdown func (s *shutdownmanagerContext) shutdownReadyHandler(w http.ResponseWriter, r *http.Request) {+	// For testing, the filepath and check period can be overridden in the context+	// Otherwise, use the module constants+	var signalFilepath string+	if s.shutdownReadyFile != "" {+		signalFilepath = s.shutdownReadyFile+	} else {+		signalFilepath = shutdownReadyFile+	}+	var signalFileCheckDuration time.Duration+	if s.shutdownReadyCheckInterval != 0 {+		signalFileCheckDuration = s.shutdownReadyCheckInterval+	} else {+		signalFileCheckDuration = shutdownReadyCheckInterval+	}

+---+title: Using Gatekeeper as a validating admission controller with Contour+layout: page+---++This tutorial demonstrates how to use [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) as a validating admission controller for Contour.++Gatekeeper is a project that enables users to define flexible policies for Kubernetes resources using [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) that are enforced when those resources are created/updated via the Kubernetes API.++The benefits of using Gatekeeper with Contour are:+- Immediate feedback for the user when they try to create an `HTTPProxy` with an invalid spec. Instead of having to check the `HTTPProxy`'s status after creation for a possible error message, the create is rejected and the user is immediately provided with a reason for the rejection.+- User-defined policies for `HTTPProxy` specs. For example, the Contour admin can define policies to enforce maximum limits on timeouts and retries, disallow certain FQDNs, etc.++## Prerequisites++- A Kubernetes cluster with a minimum version of 1.14 (to enable webhook timeouts for Gatekeeper).+- Cluster-admin permissions++## Deploy Contour++Run:++```bash+$ kubectl apply -f {{ site.url }}/quickstart/contour.yaml+```++This creates a `projectcontour` namespace and sets up Contour as a deployment and Envoy as a daemonset, with communication between them secured by mutual TLS.++Check the status of the Contour pods with this command:++```bash+$ kubectl -n projectcontour get pods -l app=contour+NAME                           READY   STATUS      RESTARTS   AGE+contour-8596d6dbd7-9nrg2       1/1     Running     0          32m+contour-8596d6dbd7-mmtc8       1/1     Running     0          32m+```++If installation was successful, all pods should reach `Running` status shortly.++## Deploy Gatekeeper++The following instructions are summarized from the [Gatekeeper documentation](https://github.com/open-policy-agent/gatekeeper#installation-instructions).++Run:++```bash+$ kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml+```++This creates a `gatekeeper-system` namespace and sets up the Gatekeeper controller manager and audit deployments using the latest Gatekeeper release.++Check the status of the Gatekeeper pods with this command:++```bash+$ kubectl -n gatekeeper-system get pods+NAME                                             READY   STATUS    RESTARTS   AGE+gatekeeper-audit-67dfc46db6-kjcmc                1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-64hhn   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-c4dkd   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-xv9jn   1/1     Running   0          40m+```++If installation was successful, all pods should reach `Running` status shortly.++## Configure Gatekeeper++### Background++Gatekeeper uses the [OPA Constraint Framework](https://github.com/open-policy-agent/frameworks/tree/master/constraint) to define and enforce policies.+This framework has two key types: `ConstraintTemplate` and `Constraint`.+A `ConstraintTemplate` defines a reusable OPA policy, along with the parameters that can be passed to it when it is instantiated.+When a `ConstraintTemplate` is created, Gatekeeper automatically creates a custom resource definition (CRD) to represent it in the cluster.++A `Constraint` is an instantiation of a `ConstraintTemplate`, which tells Gatekeeper to apply it to specific Kubernetes resource types (e.g. `HTTPProxy`) and provides any relevant parameter values.+A `Constraint` is defined as an instance of the CRD representing the associated `ConstraintTemplate`.++We'll now look at some examples to make these concepts concrete.++### Configure resource caching++First, Gatekeeper needs to be configured to store all `HTTPProxy` resources in its internal cache, so that existing `HTTPProxy` resources can be referenced within constraint template policies.+This is essential for being able to define constraints that look across all `HTTPProxies` -- for example, to verify FQDN uniqueness.++Create a file called `config.yml` containing the following YAML:++```yaml+apiVersion: config.gatekeeper.sh/v1alpha1+kind: Config+metadata:+  name: config+  namespace: "gatekeeper-system"+spec:+  sync:+    syncOnly:+      - group: "projectcontour.io"+        version: "v1"+        kind: "HTTPProxy"+```++Apply it to the cluster:++```bash+$ kubectl apply -f config.yml+```++### Configure HTTPProxy validations++The first constraint template and constraint that we'll define are what we'll refer to as a **validation**.+These are rules for `HTTPProxy` specs that Contour universally requires to be true.+In this example, we'll define a constraint template and constraint to enforce that all `HTTPProxies` must have a unique FQDN.++Create a file called `unique-fqdn-template.yml` containing the following YAML:++```yaml+apiVersion: templates.gatekeeper.sh/v1beta1+kind: ConstraintTemplate+metadata:+  name: httpproxyuniquefqdn+spec:+  crd:+    spec:+      names:+        kind: HTTPProxyUniqueFQDN+        listKind: HTTPProxyUniqueFQDNList+        plural: HTTPProxyUniqueFQDNs+        singular: HTTPProxyUniqueFQDN+  targets:+    - target: admission.k8s.gatekeeper.sh+      rego: |+        package httpproxy.uniquefqdn++        violation[{"msg": msg, "other": sprintf("%v/%v", [other.metadata.namespace, other.metadata.name])}] {+          got := input.review.object.spec.virtualhost.fqdn+          other := data.inventory.namespace[_]["projectcontour.io/v1"]["HTTPProxy"][_]+          other.spec.virtualhost.fqdn = got++          not same(other, input.review.object)+          msg := "HTTPProxy must have a unique spec.virtualhost.fqdn"+        }++        same(a, b) {+          a.metadata.namespace == b.metadata.namespace+          a.metadata.name == b.metadata.name+        }+```++Apply it to the cluster:++```bash+$ kubectl apply -f unique-fqdn-template.yml+```++Within a few seconds, you'll see that a corresponding CRD has been created in the cluster:++```bash+$ kubectl get crd httpproxyuniquefqdn.constraints.gatekeeper.sh+NAME                                            CREATED AT+httpproxyuniquefqdn.constraints.gatekeeper.sh   2020-08-13T16:08:57Z+```++Now, create a file called `unique-fqdn-constraint.yml` containing the following YAML:++```yaml+apiVersion: constraints.gatekeeper.sh/v1beta1+kind: HTTPProxyUniqueFQDN+metadata:+  name: httpproxy-unique-fqdn+spec:+  match:+    kinds:+      - apiGroups: ["projectcontour.io"]+        kinds: ["HTTPProxy"]+```++Note that the `Kind` of this resource corresponds to the new CRD.++Apply it to the cluster:++```bash+$ kubectl apply -f unique-fqdn-constraint.yml+```++Now, let's create some `HTTPProxies` to see the validation in action.++Create a file called `httpproxies.yml` containing the following YAML:++```yaml+apiVersion: projectcontour.io/v1+kind: HTTPProxy+metadata:+  name: demo+  namespace: default+spec:+  virtualhost:+    fqdn: demo.projectcontour.io+---+apiVersion: projectcontour.io/v1+kind: HTTPProxy+metadata:+  name: demo2+  namespace: default+spec:+  virtualhost:+    fqdn: demo.projectcontour.io+```++Note that both `HTTPProxies` have the same FQDN.++Apply the YAML:++```bash+$ kubectl apply -f httpproxies.yml+```++You should see something like:+```+httpproxy.projectcontour.io/demo created+Error from server ([denied by httpproxy-unique-fqdn] HTTPProxy must have a unique FQDN): error when creating "httpproxies.yml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by httpproxy-unique-fqdn] HTTPProxy must have a unique FQDN+```++The first `HTTPProxy` was created successfully, because there was not already an existing proxy with the `demo.projectcontour.io` FQDN.+However, when the second `HTTPProxy` was submitted, Gatekeeper rejected its creation because it used the same FQDN as the first one.++### Configure HTTPProxy policies++The next constraint template and constraint that we'll create are what we refer to as a **policy**.+These are rules for `HTTPProxy` specs that an individual Contour administrator may want to enforce for their cluster, but that are not explicitly required by Contour itself.+In this example, we'll define a constraint template and constraint to enforce that all `HTTPProxies` can be configured with at most five retries for any route.++Create a file called `retry-count-range-template.yml` containing the following YAML:++```yaml+apiVersion: templates.gatekeeper.sh/v1beta1+kind: ConstraintTemplate+metadata:+  name: httpproxyretrycountrange+spec:+  crd:+    spec:+      names:+        kind: HTTPProxyRetryCountRange+        listKind: HTTPProxyRetryCountRangeList+        plural: HTTPProxyRetryCountRanges+        singular: HTTPProxyRetryCountRange+      scope: Namespaced+      validation:+        openAPIV3Schema:+          properties:+            min:+              type: integer+            max: +              type: integer+  targets:+    - target: admission.k8s.gatekeeper.sh+      rego: |+        package httpproxy.retrycountrange++        violation[{"msg": msg}] {+          got := input.review.object.spec.routes[_].retryPolicy.count++          got > input.parameters.max+          msg := sprintf("retry policy count must be less than/equal to %v", [input.parameters.max])+        }++        violation[{"msg": msg}] {+          got := input.review.object.spec.routes[_].retryPolicy.count++          got < input.parameters.min+          msg := sprintf("retry policy count must be greater than/equal to %v", [input.parameters.min])+        }+```++Apply it to the cluster:++```bash+$ kubectl apply -f retry-count-range-template.yml+```++Again, within a few seconds, you'll see that a corresponding CRD has been created in the cluster:++```bash+$ kubectl get crd httpproxyretrycountrange.constraints.gatekeeper.sh+NAME                                                 CREATED AT+httpproxyretrycountrange.constraints.gatekeeper.sh   2020-08-13T16:12:10Z+```++Now, create a file called `retry-count-range-constraint.yml` containing the following YAML:++```yaml+apiVersion: constraints.gatekeeper.sh/v1beta1+kind: HTTPProxyRetryCountRange+metadata:+  name: httpproxy-retry-count-range

+---+title: Using Gatekeeper as a validating admission controller with Contour+layout: page+---++This tutorial demonstrates how to use [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) as a validating admission controller for Contour.++Gatekeeper is a project that enables users to define flexible policies for Kubernetes resources using [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) that are enforced when those resources are created/updated via the Kubernetes API.++The benefits of using Gatekeeper with Contour are:+- Immediate feedback for the user when they try to create an `HTTPProxy` with an invalid spec. Instead of having to check the `HTTPProxy`'s status after creation for a possible error message, the create is rejected and the user is immediately provided with a reason for the rejection.+- User-defined policies for `HTTPProxy` specs. For example, the Contour admin can define policies to enforce maximum limits on timeouts and retries, disallow certain FQDNs, etc.++## Prerequisites++- A Kubernetes cluster with a minimum version of 1.14 (to enable webhook timeouts for Gatekeeper).+- Cluster-admin permissions++## Deploy Contour++Run:++```bash+$ kubectl apply -f {{ site.url }}/quickstart/contour.yaml+```++This creates a `projectcontour` namespace and sets up Contour as a deployment and Envoy as a daemonset, with communication between them secured by mutual TLS.++Check the status of the Contour pods with this command:++```bash+$ kubectl -n projectcontour get pods -l app=contour+NAME                           READY   STATUS      RESTARTS   AGE+contour-8596d6dbd7-9nrg2       1/1     Running     0          32m+contour-8596d6dbd7-mmtc8       1/1     Running     0          32m+```++If installation was successful, all pods should reach `Running` status shortly.++## Deploy Gatekeeper++The following instructions are summarized from the [Gatekeeper documentation](https://github.com/open-policy-agent/gatekeeper#installation-instructions).++Run:++```bash+$ kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml+```++This creates a `gatekeeper-system` namespace and sets up the Gatekeeper controller manager and audit deployments using the latest Gatekeeper release.++Check the status of the Gatekeeper pods with this command:++```bash+$ kubectl -n gatekeeper-system get pods+NAME                                             READY   STATUS    RESTARTS   AGE+gatekeeper-audit-67dfc46db6-kjcmc                1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-64hhn   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-c4dkd   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-xv9jn   1/1     Running   0          40m+```++If installation was successful, all pods should reach `Running` status shortly.++## Configure Gatekeeper++### Background++Gatekeeper uses the [OPA Constraint Framework](https://github.com/open-policy-agent/frameworks/tree/master/constraint) to define and enforce policies.+This framework has two key types: `ConstraintTemplate` and `Constraint`.+A `ConstraintTemplate` defines a reusable OPA policy, along with the parameters that can be passed to it when it is instantiated.+When a `ConstraintTemplate` is created, Gatekeeper automatically creates a custom resource definition (CRD) to represent it in the cluster.++A `Constraint` is an instantiation of a `ConstraintTemplate`, which tells Gatekeeper to apply it to specific Kubernetes resource types (e.g. `HTTPProxy`) and provides any relevant parameter values.+A `Constraint` is defined as an instance of the CRD representing the associated `ConstraintTemplate`.++We'll now look at some examples to make these concepts concrete.++### Configure resource caching++First, Gatekeeper needs to be configured to store all `HTTPProxy` resources in its internal cache, so that existing `HTTPProxy` resources can be referenced within constraint template policies.+This is essential for being able to define constraints that look across all `HTTPProxies` -- for example, to verify FQDN uniqueness.++Create a file called `config.yml` containing the following YAML:++```yaml+apiVersion: config.gatekeeper.sh/v1alpha1+kind: Config+metadata:+  name: config+  namespace: "gatekeeper-system"+spec:+  sync:+    syncOnly:+      - group: "projectcontour.io"+        version: "v1"+        kind: "HTTPProxy"+```++Apply it to the cluster:++```bash+$ kubectl apply -f config.yml+```++### Configure HTTPProxy validations++The first constraint template and constraint that we'll define are what we'll refer to as a **validation**.+These are rules for `HTTPProxy` specs that Contour universally requires to be true.+In this example, we'll define a constraint template and constraint to enforce that all `HTTPProxies` must have a unique FQDN.++Create a file called `unique-fqdn-template.yml` containing the following YAML:++```yaml+apiVersion: templates.gatekeeper.sh/v1beta1+kind: ConstraintTemplate+metadata:+  name: httpproxyuniquefqdn+spec:+  crd:+    spec:+      names:+        kind: HTTPProxyUniqueFQDN+        listKind: HTTPProxyUniqueFQDNList+        plural: HTTPProxyUniqueFQDNs+        singular: HTTPProxyUniqueFQDN+  targets:+    - target: admission.k8s.gatekeeper.sh+      rego: |+        package httpproxy.uniquefqdn++        violation[{"msg": msg, "other": sprintf("%v/%v", [other.metadata.namespace, other.metadata.name])}] {+          got := input.review.object.spec.virtualhost.fqdn+          other := data.inventory.namespace[_]["projectcontour.io/v1"]["HTTPProxy"][_]

+---+title: Using Gatekeeper as a validating admission controller with Contour+layout: page+---++This tutorial demonstrates how to use [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) as a validating admission controller for Contour.++Gatekeeper is a project that enables users to define flexible policies for Kubernetes resources using [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) that are enforced when those resources are created/updated via the Kubernetes API.++The benefits of using Gatekeeper with Contour are:+- Immediate feedback for the user when they try to create an `HTTPProxy` with an invalid spec. Instead of having to check the `HTTPProxy`'s status after creation for a possible error message, the create is rejected and the user is immediately provided with a reason for the rejection.+- User-defined policies for `HTTPProxy` specs. For example, the Contour admin can define policies to enforce maximum limits on timeouts and retries, disallow certain FQDNs, etc.++## Prerequisites++- A Kubernetes cluster with a minimum version of 1.14 (to enable webhook timeouts for Gatekeeper).+- Cluster-admin permissions++## Deploy Contour++Run:++```bash+$ kubectl apply -f {{ site.url }}/quickstart/contour.yaml+```++This creates a `projectcontour` namespace and sets up Contour as a deployment and Envoy as a daemonset, with communication between them secured by mutual TLS.++Check the status of the Contour pods with this command:++```bash+$ kubectl -n projectcontour get pods -l app=contour+NAME                           READY   STATUS      RESTARTS   AGE+contour-8596d6dbd7-9nrg2       1/1     Running     0          32m+contour-8596d6dbd7-mmtc8       1/1     Running     0          32m+```++If installation was successful, all pods should reach `Running` status shortly.++## Deploy Gatekeeper++The following instructions are summarized from the [Gatekeeper documentation](https://github.com/open-policy-agent/gatekeeper#installation-instructions).++Run:++```bash+$ kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml+```++This creates a `gatekeeper-system` namespace and sets up the Gatekeeper controller manager and audit deployments using the latest Gatekeeper release.++Check the status of the Gatekeeper pods with this command:++```bash+$ kubectl -n gatekeeper-system get pods+NAME                                             READY   STATUS    RESTARTS   AGE+gatekeeper-audit-67dfc46db6-kjcmc                1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-64hhn   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-c4dkd   1/1     Running   0          40m+gatekeeper-controller-manager-7cbc758844-xv9jn   1/1     Running   0          40m+```++If installation was successful, all pods should reach `Running` status shortly.++## Configure Gatekeeper++### Background++Gatekeeper uses the [OPA Constraint Framework](https://github.com/open-policy-agent/frameworks/tree/master/constraint) to define and enforce policies.+This framework has two key types: `ConstraintTemplate` and `Constraint`.+A `ConstraintTemplate` defines a reusable OPA policy, along with the parameters that can be passed to it when it is instantiated.+When a `ConstraintTemplate` is created, Gatekeeper automatically creates a custom resource definition (CRD) to represent it in the cluster.++A `Constraint` is an instantiation of a `ConstraintTemplate`, which tells Gatekeeper to apply it to specific Kubernetes resource types (e.g. `HTTPProxy`) and provides any relevant parameter values.+A `Constraint` is defined as an instance of the CRD representing the associated `ConstraintTemplate`.++We'll now look at some examples to make these concepts concrete.++### Configure resource caching++First, Gatekeeper needs to be configured to store all `HTTPProxy` resources in its internal cache, so that existing `HTTPProxy` resources can be referenced within constraint template policies.+This is essential for being able to define constraints that look across all `HTTPProxies` -- for example, to verify FQDN uniqueness.