|
| 1 | +# JWKS |
| 2 | + |
| 3 | +In this example we deploy a web application, configure load balancing with a VirtualServer, and apply a JWT policy. |
| 4 | +Instead of using a local secret to verify the client request such as in the |
| 5 | +[jwt](https://github.com/nginx/kubernetes-ingress/tree/main/examples/custom-resources/jwt) example, we will define an |
| 6 | +external Identity Provider (IdP) using the `JwksURI` field. |
| 7 | + |
| 8 | +We will be using a deployment of [KeyCloak](https://www.keycloak.org/) to work as our IdP in this example. In this |
| 9 | +example, KeyCloak is deployed as a single container for the purpose of exposing it with an Ingress Controller. |
| 10 | + |
| 11 | +## Prerequisites |
| 12 | + |
| 13 | +1. Follow the [installation](https://docs.nginx.com/nginx-ingress-controller/installation/installation-with-manifests/) |
| 14 | + instructions to deploy the Ingress Controller. |
| 15 | + |
| 16 | +2. Save the public IP address of the Ingress Controller into `/etc/hosts` of your machine: |
| 17 | + |
| 18 | + ```text |
| 19 | + ... |
| 20 | +
|
| 21 | + XXX.YYY.ZZZ.III webapp.example.com |
| 22 | + XXX.YYY.ZZZ.III keycloak.example.com |
| 23 | + ``` |
| 24 | +
|
| 25 | + Here `webapp.example.com` is the domain for the web application and `keycloak.example.com` is the domain for |
| 26 | + Keycloak. |
| 27 | +
|
| 28 | +## Step 1 - Deploy a TLS Secret |
| 29 | +
|
| 30 | +Create a secret with the TLS certificate and key that will be used for TLS termination of the Keycloak application: |
| 31 | +
|
| 32 | +```console |
| 33 | +kubectl apply -f tls-secret.yaml |
| 34 | +``` |
| 35 | + |
| 36 | +## Step 2 - Deploy a Web Application |
| 37 | + |
| 38 | +Create the application deployment and service: |
| 39 | + |
| 40 | +```console |
| 41 | +kubectl apply -f webapp.yaml |
| 42 | +``` |
| 43 | + |
| 44 | +## Step 3 - Deploy Keycloak |
| 45 | + |
| 46 | +1. Create the Keycloak deployment and service: |
| 47 | + |
| 48 | + ```console |
| 49 | + kubectl apply -f keycloak.yaml |
| 50 | + ``` |
| 51 | + |
| 52 | +1. Create a VirtualServer resource for Keycloak: |
| 53 | + |
| 54 | + ```console |
| 55 | + kubectl apply -f virtual-server-idp.yaml |
| 56 | + ``` |
| 57 | + |
| 58 | +## Step 4 - Configure Keycloak |
| 59 | + |
| 60 | +To set up Keycloak: |
| 61 | + |
| 62 | +1. To connect to Keycloak, use `https://keycloak.example.com`. |
| 63 | + |
| 64 | +2. Create a new Realm. We will use `jwks-example` for this example. This can be done by selecting the dropdown menu on |
| 65 | + the left and selecting `Create Realm` |
| 66 | + |
| 67 | +3. Create a new Client called `jwks-client`. This can be done by selecting the `Client`s tab on the left and then |
| 68 | + selecting `Create client`. |
| 69 | + - When creating the Client, ensure both `Client authentication` and `Authorization` are enabled. |
| 70 | + |
| 71 | +4. Once the client is created, navigate to the `Credentials` tab for that client and copy the client secret. |
| 72 | + - This can be saved in the `SECRET` shell variable for later: |
| 73 | + |
| 74 | + ```console |
| 75 | + export SECRET=<client secret> |
| 76 | + ``` |
| 77 | + |
| 78 | +5. Create a new User called `jwks-user` by selecting the Users tab on the left and then selecting Create client. |
| 79 | + |
| 80 | +6. Once the user is created, navigate to the `Credentials` tab for that user and select `Set password`. For this example |
| 81 | + the password can be whatever you want. |
| 82 | + - This can be saved in the `PASSWORD` shell variable for later: |
| 83 | + |
| 84 | + ```console |
| 85 | + export PASSWORD=<user password> |
| 86 | + ``` |
| 87 | + |
| 88 | +## Step 5 - Deploy the JWT Policy |
| 89 | + |
| 90 | +Create a policy with the name `jwt-policy` and configure the `JwksURI` field so that it only permits requests to our |
| 91 | +web application that contain a valid JWT. In the example policy below, replace `<your_realm>` with the realm created in |
| 92 | +Step 4. We used `jwks-example` as our realm name. The value of `spec.jwt.token` is set to `$http_token` in this example |
| 93 | +as we are sending the client token in an HTTP header. |
| 94 | + |
| 95 | + ```yaml |
| 96 | + apiVersion: k8s.nginx.org/v1 |
| 97 | + kind: Policy |
| 98 | + metadata: |
| 99 | + name: jwt-policy |
| 100 | + spec: |
| 101 | + jwt: |
| 102 | + realm: MyProductAPI |
| 103 | + token: $http_token |
| 104 | + jwksURI: http://keycloak.default.svc.cluster.local:8080/realms/<your_realm>/protocol/openid-connect/certs |
| 105 | + keyCache: 1h |
| 106 | + ``` |
| 107 | + |
| 108 | +Deploy the policy: |
| 109 | + |
| 110 | + ```console |
| 111 | + kubectl apply -f jwks.yaml |
| 112 | + ``` |
| 113 | + |
| 114 | +## Step 6 - Deploy a config map with a resolver |
| 115 | + |
| 116 | +If the value of `jwksURI` uses a hostname, the Ingress Controller will need to reference a resolver. This can be done by |
| 117 | +deploying a ConfigMap with the `resolver-addresses` data field |
| 118 | + |
| 119 | +```yaml |
| 120 | +kind: ConfigMap |
| 121 | +apiVersion: v1 |
| 122 | +metadata: |
| 123 | + name: nginx-config |
| 124 | + namespace: nginx-ingress |
| 125 | +data: |
| 126 | + resolver-addresses: <resolver-address> |
| 127 | +``` |
| 128 | +
|
| 129 | +In this example, we create a ConfigMap using Kubernetes' default DNS `kube-dns.kube-system.svc.cluster.local` for the |
| 130 | +resolver address. For more information on `resolver-addresses` and other related ConfigMap keys, please refer to our |
| 131 | +documentation [ConfigMap |
| 132 | +Resource](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#summary-of-configmap-keys) |
| 133 | +and our blog post [Using DNS for Service Discovery with NGINX and NGINX |
| 134 | +Plus](https://www.nginx.com/blog/dns-service-discovery-nginx-plus) |
| 135 | + |
| 136 | +NOTE: When setting the value of `jwksURI` in Step 5, the response will differ depending on the IDP used. In some cases |
| 137 | +the response will be too large for NGINX to properly handle. If this occurs you will need to configure the |
| 138 | +[subrequest_output_buffer_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#subrequest_output_buffer_size) |
| 139 | +directive in the http context. This can currently be done using `http-snippets`. Please refer to our document on |
| 140 | +[snippets and custom |
| 141 | +templates](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#snippets-and-custom-templates) |
| 142 | +for details on how to configure this directive. |
| 143 | + |
| 144 | +The code block below is an example of the updated configmap which adds `subrequest_output_buffer_size` under the http |
| 145 | +context in the nginx.conf. |
| 146 | + |
| 147 | +NOTE: The value of `subrequest_output_buffer_size` is only an example value and should be changed to suit your |
| 148 | +environment. |
| 149 | + |
| 150 | +```yaml |
| 151 | +kind: ConfigMap |
| 152 | +apiVersion: v1 |
| 153 | +metadata: |
| 154 | + name: nginx-config |
| 155 | + namespace: nginx-ingress |
| 156 | +data: |
| 157 | + resolver-addresses: <resolver-address> |
| 158 | + http-snippets: | |
| 159 | + subrequest_output_buffer_size 64k; |
| 160 | +``` |
| 161 | + |
| 162 | +```console |
| 163 | +kubectl apply -f nginx-config.yaml |
| 164 | +``` |
| 165 | + |
| 166 | +## Step 7 - Configure Load Balancing |
| 167 | + |
| 168 | +Create a VirtualServer resource for the web application: |
| 169 | + |
| 170 | +```console |
| 171 | +kubectl apply -f virtual-server.yaml |
| 172 | +``` |
| 173 | + |
| 174 | +Note that the VirtualServer references the policy `jwt-policy` created in Step 5. |
| 175 | + |
| 176 | +## Step 8 - Get the client token |
| 177 | + |
| 178 | +For the client to have permission to send requests to the web application they must send a Bearer token to the |
| 179 | +application. To get this token, run the following `curl` command: |
| 180 | + |
| 181 | +```console |
| 182 | +export TOKEN=$(curl -k -L -X POST 'https://keycloak.example.com/realms/jwks-example/protocol/openid-connect/token' \ |
| 183 | +-H 'Content-Type: application/x-www-form-urlencoded' \ |
| 184 | +--data-urlencode grant_type=password \ |
| 185 | +--data-urlencode scope=openid \ |
| 186 | +--data-urlencode client_id=jwks-client \ |
| 187 | +--data-urlencode client_secret=$SECRET \ |
| 188 | +--data-urlencode username=jwks-user \ |
| 189 | +--data-urlencode password=$PASSWORD \ |
| 190 | +| jq -r .access_token) |
| 191 | +``` |
| 192 | + |
| 193 | +This command will save the token in the `TOKEN` shell variable. |
| 194 | + |
| 195 | +## Step 9 - Test the Configuration |
| 196 | + |
| 197 | +If you attempt to access the application without providing the bearer token, NGINX will reject your requests for that |
| 198 | +VirtualServer: |
| 199 | + |
| 200 | +```console |
| 201 | +curl -H 'Accept: application/json' webapp.example.com |
| 202 | +``` |
| 203 | + |
| 204 | +```text |
| 205 | +<html> |
| 206 | +<head><title>401 Authorization Required</title></head> |
| 207 | +<body> |
| 208 | +<center><h1>401 Authorization Required</h1></center> |
| 209 | +</body> |
| 210 | +</html> |
| 211 | +``` |
| 212 | + |
| 213 | +If a valid bearer token is provided, the request will succeed: |
| 214 | + |
| 215 | +```console |
| 216 | +curl -H 'Accept: application/json' -H "token: ${TOKEN}" webapp.example.com |
| 217 | +``` |
| 218 | + |
| 219 | +```text |
| 220 | +Server address: 10.42.0.7:8080 |
| 221 | +Server name: webapp-5c6fdbcbf9-pt9tp |
| 222 | +Date: 13/Dec/2022:14:50:33 +0000 |
| 223 | +URI: / |
| 224 | +Request ID: f1241390ac51318afa4fcc39d2341359 |
| 225 | +``` |
0 commit comments