You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -63,14 +63,14 @@ Next, build and deploy the color app images.
63
63
64
64
```bash
65
65
./src/colorteller/deploy.sh
66
-
./src/gateway/deploy.sh
66
+
./src/frontend/deploy.sh
67
67
```
68
68
69
69
Note that the example apps use go modules. If you have trouble accessing https://proxy.golang.org during the deployment you can override the GOPROXY by setting `GO_PROXY=direct`
70
70
71
71
```bash
72
72
GO_PROXY=direct ./src/colorteller/deploy.sh
73
-
GO_PROXY=direct ./src/gateway/deploy.sh
73
+
GO_PROXY=direct ./src/frontend/deploy.sh
74
74
```
75
75
76
76
## Step 2: Generate the Certficates
@@ -161,7 +161,7 @@ Now with the mesh defined, we can deploy our service to ECS and test it out.
You should see output similar to: `listener.0.0.0.0_15000.ssl.handshake: 1`, indicating a successful SSL handshake was achieved between gateway and color teller.
185
+
You should see output similar to: `listener.0.0.0.0_15000.ssl.handshake: 1`, indicating a successful SSL handshake was achieved between frontend and color teller.
186
186
187
187
Check out the [TLS Encryption](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual-node-tls.html) documentation for more information on enabling encryption between services in App Mesh.
188
188
189
189
## Client TLS Validation Tutorial
190
190
191
-
Enabling TLS communication from your virtual node is the first step to securing your traffic. In a zero trust system, the Color Gateway should also be responsible for defining what certificate authorities are trusted. App Mesh allows you to configure Envoy with information on what CAs you trust to vend certificates. We will demonstrate this by adding a new color teller to our service that has a TLS certificate vended from a different CA than the first.
191
+
Enabling TLS communication from your virtual node is the first step to securing your traffic. In a zero trust system, the frontend should also be responsible for defining what certificate authorities are trusted. App Mesh allows you to configure Envoy with information on what CAs you trust to vend certificates. We will demonstrate this by adding a new color teller to our service that has a TLS certificate vended from a different CA than the first.
192
192
193
193
## Step 6: Add the Green Color Teller
194
194
@@ -227,15 +227,15 @@ After a couple seconds, when you hit the service, you should see both green and
227
227
curl "${COLORAPP_ENDPOINT}/color"
228
228
```
229
229
230
-
### Step 7: Add TLS Validation to the Gateway
230
+
### Step 7: Add TLS Validation to the Frontend
231
231
232
-
As you just saw, we were able to add a new Virtual Node with TLS to our mesh and the Color Gateway was able to communicate with it no problem.
232
+
As you just saw, we were able to add a new Virtual Node with TLS to our mesh and the Frontend was able to communicate with it no problem.
233
233
234
234
In the client/server relationship, if the server decides to turn on TLS, App Mesh configures the client Envoys to accept the certificate offered. However, clients should also validate that the certificate offered by the server is from a certificate authority they trust. App Mesh allows you to define a client policy for TLS validation to ensure that the certificate is valid and issued from a trustworthy source.
235
235
236
236
If you recall, the Green Color Teller certificates were signed by a different CA than the White Color Teller certificates. Perhaps this is not the intended behavior and we want to reject certificates from any CA that is not CA 1.
237
237
238
-
We are going to update the Color Gateway backend to have this configuration:
238
+
We are going to update the Frontend's backend to have this configuration:
239
239
240
240
```yaml
241
241
Backends:
@@ -254,7 +254,7 @@ BackendDefaults:
254
254
In this situation, we add a backend default for the Client Policy that instructs Envoy to only allow certificates signed by CA 1 to be accepted. If we had a separate backend with a `ClientPolicy` defined for `TLS`, then the default policy would not be applied for `TLS`.
255
255
256
256
```bash
257
-
./mesh/mesh.sh updateGateway
257
+
./mesh/mesh.sh updateFrontend
258
258
```
259
259
260
260
Now when call the service, you will see `white` is working properly, but you will start to see `upstream connect error or disconnect/reset before headers. reset reason: connection failure` from the Green Colorteller.
We can restore communication by changing the `certificateChain` in the backend group to be `ca_1_ca_2_bundle.pem`. This contains both the public certificates for CA 1 and CA 2, which will instructs Envoy to accept certificates signed by both CA 1 and CA 2.
269
269
270
270
```bash
271
-
./mesh/mesh.sh updateGateway2
271
+
./mesh/mesh.sh updateFrontend2
272
272
```
273
273
274
274
Now when you call the service, you will see both `white` and `green` again.
@@ -292,7 +292,7 @@ Run the following commands to clean up and tear down the resources that we’ve
0 commit comments