hashicorp · jm96441n · Sep 15, 2023 · Aug 25, 2023 · Sep 7, 2023 · Sep 7, 2023
diff --git a/.changelog/2962.txt b/.changelog/2962.txt
@@ -0,0 +1,3 @@
+```releast-note:feature
+api-gateway: (Consul Enterprise) Add JWT authentication and authorization for API Gateway and HTTPRoutes.
+```
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -7,7 +7,7 @@
     1. [Running linters locally](#running-linters-locally)
     1. [Rebasing contributions against main](#rebasing-contributions-against-main)
 1. [Creating a new CRD](#creating-a-new-crd)
-    1. [The Structs](#the-structs) 
+    1. [The Structs](#the-structs)
     1. [Spec Methods](#spec-methods)
     1. [Spec Tests](#spec-tests)
     1. [Controller](#controller)
@@ -31,13 +31,13 @@
 
 ### Building and running `consul-k8s-control-plane`
 
-To build and install the control plane binary `consul-k8s-control-plane` locally, Go version 1.17.0+ is required. 
+To build and install the control plane binary `consul-k8s-control-plane` locally, Go version 1.17.0+ is required.
 You will also need to install the Docker engine:
 
 - [Docker for Mac](https://docs.docker.com/engine/installation/mac/)
 - [Docker for Windows](https://docs.docker.com/engine/installation/windows/)
 - [Docker for Linux](https://docs.docker.com/engine/installation/linux/ubuntulinux/)
- 
+
 Install [gox](https://github.com/mitchellh/gox) (v1.14+). For Mac and Linux:
   ```bash
   brew install gox
@@ -102,7 +102,7 @@ controller:
   enabled: true
 ```
 
-Run a `helm install` from the project root directory to target your dev version of the Helm chart. 
+Run a `helm install` from the project root directory to target your dev version of the Helm chart.
 
 ```shell
 helm install consul --create-namespace -n consul -f ./values.dev.yaml ./charts/consul
@@ -125,7 +125,7 @@ consul-k8s version
 
 ### Making changes to consul-k8s
 
-The first step to making changes is to fork Consul K8s. Afterwards, the easiest way 
+The first step to making changes is to fork Consul K8s. Afterwards, the easiest way
 to work on the fork is to set it as a remote of the Consul K8s project:
 
 1. Rename the existing remote's name: `git remote rename origin upstream`.
@@ -164,7 +164,7 @@ rebase the branch on main, fixing any conflicts along the way before the code ca
 ## Creating a new CRD
 
 ### The Structs
-1. Run the generate command:
+1. Run the generate command from the `control-plane` directory: (installation instructions for `operator-sdk` found [here](https://sdk.operatorframework.io/docs/installation/):
     ```bash
     operator-sdk create api --group consul --version v1alpha1 --kind IngressGateway --controller --namespaced=true --make=false --resource=true
     ```
@@ -173,37 +173,37 @@ rebase the branch on main, fixing any conflicts along the way before the code ca
     func init() {
     	SchemeBuilder.Register(&IngressGateway{}, &IngressGatewayList{})
     }
-    
+
     // +kubebuilder:object:root=true
     // +kubebuilder:subresource:status
-    
+
     // IngressGateway is the Schema for the ingressgateways API
     type IngressGateway struct {
     	metav1.TypeMeta   `json:",inline"`
     	metav1.ObjectMeta `json:"metadata,omitempty"`
-    
+
     	Spec   IngressGatewaySpec   `json:"spec,omitempty"`
     	Status IngressGatewayStatus `json:"status,omitempty"`
     }
-    
+
     // +kubebuilder:object:root=true
-    
+
     // IngressGatewayList contains a list of IngressGateway
     type IngressGatewayList struct {
     	metav1.TypeMeta `json:",inline"`
     	metav1.ListMeta `json:"metadata,omitempty"`
     	Items           []IngressGateway `json:"items"`
     }
-    
+
     // IngressGatewaySpec defines the desired state of IngressGateway
     type IngressGatewaySpec struct {
     	// INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
     	// Important: Run "make" to regenerate code after modifying this file
-    
+
     	// Foo is an example field of IngressGateway. Edit IngressGateway_types.go to remove/update
     	Foo string `json:"foo,omitempty"`
     }
-    
+
     // IngressGatewayStatus defines the observed state of IngressGateway
     type IngressGatewayStatus struct {
     	// INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
@@ -225,7 +225,7 @@ rebase the branch on main, fixing any conflicts along the way before the code ca
     type IngressGateway struct {
     	metav1.TypeMeta   `json:",inline"`
     	metav1.ObjectMeta `json:"metadata,omitempty"`
-    
+
     	Spec   IngressGatewaySpec   `json:"spec,omitempty"`
     -	Status IngressGatewayStatus `json:"status,omitempty"`
     +	Status `json:"status,omitempty"`
@@ -235,7 +235,7 @@ rebase the branch on main, fixing any conflicts along the way before the code ca
 1. Copy the top-level fields over into the `Spec` struct except for
    `Kind`, `Name`, `Namespace`, `Partition`, `Meta`, `CreateIndex` and `ModifyIndex`. In this
    example, the top-level fields remaining are `TLS` and `Listeners`:
-   
+
     ```go
     // IngressGatewaySpec defines the desired state of IngressGateway
     type IngressGatewaySpec struct {
@@ -261,8 +261,8 @@ rebase the branch on main, fixing any conflicts along the way before the code ca
    automatically stub out all the methods by using Code -> Generate -> IngressGateway -> ConfigEntryResource.
 1. Use existing implementations of other types to implement the methods. We have to
    copy their code because we can't use a common struct that implements the methods
-   because that messes up the CRD code generation. 
-   
+   because that messes up the CRD code generation.
+
    You should be able to follow the other "normal" types. The non-normal types
    are `ServiceIntention` and `ProxyDefault` because they have special behaviour
    around being global or their spec not matching up with Consul's directly.
@@ -273,7 +273,7 @@ rebase the branch on main, fixing any conflicts along the way before the code ca
 1. For `Validate`, we again follow the pattern of implementing the method on
    each sub-struct. You'll need to read the Consul documentation to understand
    what validation needs to be done.
-   
+
    Things to keep in mind:
    1. Re-use the `sliceContains` and `notInSliceMessage` helper methods where applicable.
    1. If the invalid field is an entire struct, encode as json (look for `asJSON` for an example).
@@ -333,7 +333,7 @@ rebase the branch on main, fixing any conflicts along the way before the code ca
     1. `TestConfigEntryControllers_doesNotCreateUnownedConfigEntry`
     1. `TestConfigEntryControllers_doesNotDeleteUnownedConfig`
 1. Note: we don't add tests to `configentry_controller_ent_test.go` because we decided
-   it's too much duplication and the controllers are already properly exercised in the oss tests. 
+   it's too much duplication and the controllers are already properly exercised in the oss tests.
 
 ### Webhook
 1. Copy an existing webhook to `control-plane/api/v1alpha/ingressgateway_webhook.go`
@@ -507,7 +507,7 @@ a token named `foo`.
       ```
     * Add `if` statement in `Run` to create your token (follow placement of other tokens).
       You'll need to decide if you need a local token (use `createLocalACL()`) or a global token (use `createGlobalACL()`).
-      
+
       ```go
       if c.flagCreateFooToken {
           err := c.createLocalACL("foo", fooRules, consulDC, isPrimary, consulClient)
@@ -588,7 +588,7 @@ The acceptance tests require a Kubernetes cluster with a configured `kubectl`.
   ```bash
   brew install python-yq
   ```
-* [Helm 3](https://helm.sh) (Currently, must use v3.8.0+.) 
+* [Helm 3](https://helm.sh) (Currently, must use v3.8.0+.)
   ```bash
   brew install kubernetes-helm
   ```
@@ -617,7 +617,7 @@ To run a specific test by name use the `--filter` flag:
     bats ./charts/consul/test/unit/<filename>.bats --filter "my test name"
 
 #### Acceptance Tests
-##### Pre-requisites 
+##### Pre-requisites
 * [gox](https://github.com/mitchellh/gox) (v1.14+)
   ```bash
   brew install gox
@@ -629,7 +629,7 @@ To run the acceptance tests:
 
     cd acceptance/tests
     go test ./... -p 1
-    
+
 The above command will run all tests that can run against a single Kubernetes cluster,
 using the current context set in your kubeconfig locally.
 
@@ -689,7 +689,7 @@ Changes to the Helm chart should be accompanied by appropriate unit tests.
 
 #### Formatting
 
-- Put tests in the test file in the same order as the variables appear in the `values.yaml`. 
+- Put tests in the test file in the same order as the variables appear in the `values.yaml`.
 - Start tests for a chart value with a header that says what is being tested, like this:
     ```
     #--------------------------------------------------------------------
@@ -710,8 +710,8 @@ In all of the tests in this repo, the base command being run is [helm template](
 In this way, we're able to test that the various conditionals in the templates render as we would expect.
 
 Each test defines the files that should be rendered using the `-x` flag, then it might adjust chart values by adding `--set` flags as well.
-The output from this `helm template` command is then piped to [yq](https://pypi.org/project/yq/). 
-`yq` allows us to pull out just the information we're interested in, either by referencing its position in the yaml file directly or giving information about it (like its length). 
+The output from this `helm template` command is then piped to [yq](https://pypi.org/project/yq/).
+`yq` allows us to pull out just the information we're interested in, either by referencing its position in the yaml file directly or giving information about it (like its length).
 The `-r` flag can be used with `yq` to return a raw string instead of a quoted one which is especially useful when looking for an exact match.
 
 The test passes or fails based on the conditional at the end that is in square brackets, which is a comparison of our expected value and the output of  `helm template` piped to `yq`.
@@ -786,11 +786,11 @@ Here are some examples of common test patterns:
       cd `chart_dir`
       assert_empty helm template \
           -s templates/sync-catalog-deployment.yaml \
-          . 
+          .
     }
     ```
     Here we are using the `assert_empty` helper command.
-    
+
 ### Writing Acceptance Tests
 
 If you are adding a feature that fits thematically with one of the existing test suites,
@@ -831,9 +831,9 @@ you need to handle that in the `TestMain` function.
 
 ```go
 func TestMain(m *testing.M) {
-    // First, create a new suite so that all flags are parsed. 	
+    // First, create a new suite so that all flags are parsed.
     suite = framework.NewSuite(m)
-    
+
     // Run the suite only if our example feature test flag is set.
     if suite.Config().EnableExampleFeature {
         os.Exit(suite.Run())
@@ -866,16 +866,16 @@ func TestExample(t *testing.T) {
   helmValues := map[string]string{
       "exampleFeature.enabled": "true",
   }
-  
-  // Generate a random name for this test. 
+
+  // Generate a random name for this test.
   releaseName := helpers.RandomName()
 
   // Create a new Consul cluster object.
   consulCluster := framework.NewHelmCluster(t, helmValues, ctx, cfg, releaseName)
-  
+
   // Create the Consul cluster with Helm.
   consulCluster.Create(t)
-    
+
   // Make test assertions.
 }
 ```
@@ -981,7 +981,7 @@ Any given test can be run either through GoLand or another IDE, or via command l
 To run all of the connect tests from command line:
 ```shell
 $ cd acceptance/tests
-$ go test ./connect/... -v -p 1 -timeout 2h -failfast -use-kind -no-cleanup-on-failure -kubecontext=kind-dc1 -secondary-kubecontext=kind-dc2 -enable-enterprise -enable-multi-cluster -debug-directory=/tmp/debug -consul-k8s-image=kyleschochenmaier/consul-k8s-acls 
+$ go test ./connect/... -v -p 1 -timeout 2h -failfast -use-kind -no-cleanup-on-failure -kubecontext=kind-dc1 -secondary-kubecontext=kind-dc2 -enable-enterprise -enable-multi-cluster -debug-directory=/tmp/debug -consul-k8s-image=kyleschochenmaier/consul-k8s-acls
 ```
 
 When running from command line a few things are important:
@@ -1129,25 +1129,25 @@ Certificate:
             X509v3 Subject Alternative Name:
                 DNS:pri-1dchdli.vault.ca.34a76791.consul, URI:spiffe://34a76791-b9b2-b93e-b0e4-1989ed11a28e.consul
 <snip>
-```         
+```
 
 ---
 
 ## Helm Reference Docs
- 
+
 The Helm reference docs (https://www.consul.io/docs/k8s/helm) are automatically
 generated from our `values.yaml` file.
 
 ### Generating Helm Reference Docs
- 
+
 To generate the docs and update the `helm.mdx` file:
 
 1. Fork `hashicorp/consul` (https://github.com/hashicorp/consul) on GitHub.
 1. Clone your fork:
    ```shell-session
    git clone https://github.com/<your-username>/consul.git
    ```
-1. Change directory into your `consul-k8s` repo: 
+1. Change directory into your `consul-k8s` repo:
    ```shell-session
    cd /path/to/consul-k8s
    ```
@@ -1216,11 +1216,11 @@ manage. One such example is the Gateway API CRDs which we use to configure API G
 Networking.
 
 To pull external CRDs into our Helm chart and make sure they get installed, we generate their configuration using
-[Kustomize](https://kustomize.io/) which can pull in Kubernetes config from external sources. We split these 
+[Kustomize](https://kustomize.io/) which can pull in Kubernetes config from external sources. We split these
 generated CRDs into individual files and store them in the `charts/consul/templates` directory.
 
-If you need to update the external CRDs we depend on, or add to them, you can do this by editing the 
-[control-plane/config/crd/external/kustomization.yaml](/control-plane/config/crd/external/kustomization.yaml) file. 
+If you need to update the external CRDs we depend on, or add to them, you can do this by editing the
+[control-plane/config/crd/external/kustomization.yaml](/control-plane/config/crd/external/kustomization.yaml) file.
 Once modified, running
 
 ```bash
@@ -1261,7 +1261,7 @@ Some common values are:
 - `control-plane`: related to control-plane functionality
 - `helm`: related to the charts module and any files, yaml, go, etc. therein
 
-There may be cases where a `code area` doesn't make sense (i.e. addressing a Go CVE). In these 
+There may be cases where a `code area` doesn't make sense (i.e. addressing a Go CVE). In these
 cases it is okay not to provide a `code area`.
 
 For more examples, look in the [`.changelog/`](../.changelog) folder for existing changelog entries.

diff --git a/charts/consul/templates/connect-inject-clusterrole.yaml b/charts/consul/templates/connect-inject-clusterrole.yaml
@@ -30,11 +30,14 @@ rules:
   - controlplanerequestlimits
   - routeretryfilters
   - routetimeoutfilters
+  - httprouteauthfilters
+  - gatewaypolicies
   {{- if .Values.global.peering.enabled }}
   - peeringacceptors
   - peeringdialers
   {{- end }}
   - jwtproviders
+  - routeauthfilters
   verbs:
   - create
   - delete
@@ -63,6 +66,8 @@ rules:
   - peeringdialers/status
   {{- end }}
   - jwtproviders/status
+  - routeauthfilters/status
+  - gatewaypolicies/status
   verbs:
   - get
   - patch
@@ -107,6 +112,7 @@ rules:
   - admissionregistration.k8s.io
   resources:
   - mutatingwebhookconfigurations
+  - validatingwebhookconfigurations
   verbs:
   - get
   - list

diff --git a/charts/consul/templates/connect-inject-validatingwebhookconfiguration.yaml b/charts/consul/templates/connect-inject-validatingwebhookconfiguration.yaml
@@ -0,0 +1,31 @@
+{{- if (or (and (ne (.Values.connectInject.enabled | toString) "-") .Values.connectInject.enabled) (and (eq (.Values.connectInject.enabled | toString) "-") .Values.global.enabled)) }}
+# The ValidatingWebhookConfiguration to enable the Connect injector.
+apiVersion: admissionregistration.k8s.io/v1
+kind: ValidatingWebhookConfiguration
+metadata:
+  name: {{ template "consul.fullname" . }}-connect-injector
+  namespace: {{ .Release.Namespace }}
+  labels:
+    app: {{ template "consul.name" . }}
+    chart: {{ template "consul.chart" . }}
+    heritage: {{ .Release.Service }}
+    release: {{ .Release.Name }}
+    component: connect-injector
+webhooks:
+- name: validate-gatewaypolicy.consul.hashicorp.com
+  matchPolicy: Equivalent
+  rules:
+  - operations: [ "CREATE" , "UPDATE" ]
+    apiGroups: [ "consul.hashicorp.com" ]
+    apiVersions: [ "v1alpha1" ]
+    resources: [ "gatewaypolicies" ]
+  failurePolicy: Fail
+  sideEffects: None
+  admissionReviewVersions:
+  - v1
+  clientConfig:
+    service:
+      name: {{ template "consul.fullname" . }}-connect-injector
+      namespace: {{ .Release.Namespace }}
+      path: /validate-v1alpha1-gatewaypolicy
+{{- end }}