online boutique’s helm chart, illustrate advanced scenarios with service mesh and gitops
Update on Dec 12th, 2022: this blog article is now on Medium.
Since the version 0.4.2, Online Boutique has its own Helm chart, in the GitHub repository or in the public Artifact Registry repository: us-docker.pkg.dev/online-boutique-ci/charts/onlineboutique
.
The intent is to simplify the way the Online Boutique users deploy it, especially when they want to deploy it in more advanced scenarios: with NetworkPolicies
, with the Cymbal branding, without the frontend
app exposed publicly, with ServiceAccounts
, etc.
Let’s see this in action throughout this blog article, from the default setup to more complex scenarios where we want a secure Online Boutique deployed in a Service Mesh. Finally, we will see how you can deploy this Helm chart via Config Sync, in a GitOps way.
Deploy the default Online Boutique
Create a GKE cluster:
Deploy the Online Boutique via its Helm chart:
If you wait a little bit, when the Pods
are deployed, you can access the Online Boutique website by clicking on this URL:
Congrats! You just deployed the default setup of Online Boutique via its Helm chart!
Secure Online Boutique with NetworkPolicies
Let’s now add more security with this default Online Boutique setup, by adding predefined fine granular NetworkPolicies
, one per app:
If you run the following command you could see the NetworkPolicies
deployed:
Output similar to:
You can verify that you can still access the Online Boutique website by clicking on this URL:
By registering your GKE clsuter in a fleet, you can even see in the Google Cloud Console that your Security posture just got improved:
Then, by navigating to the Anthos > Security page in your Google Cloud Console, you can see that Kubernetes network policy is enabled in the Online Boutique namespace:
Deploy Online Boutique in a Service Mesh
Let’s now deploy Online Boutique in an Anthos Service Mesh enabled on your GKE cluster.
First, let’s enable Anthos Service Mesh on the GKE cluster:
Wait for the managed Anthos Service Mesh to be successfully enabled on your GKE cluster (code: REVISION_READY
and state: ACTIVE
):
In order to have Online Boutique in this Service Mesh, we need to label its Namespace
:
Let’s force the injection of the Istio’s sidecar proxies on the Online Boutique’s Deployments
:
If you wait a little bit, when the Pods
are deployed, you can access the Online Boutique website by clicking on this URL:
Then, by navigating to the Anthos > Service Mesh page in your Google Cloud Console, you can see the associated Topology:
Congrats! You just deployed Online Boutique in your Service Mesh via its Helm chart!
To follow an Istio’s best practice we could even deploy fine granular Sidecars
, one per app, in order to optimize the resource utilization per app’s sidecar proxy:
If you run the following command you could see the Sidecars
deployed:
Output similar to:
Secure Online Boutique with AuthorizationPolicies
Let’s now add more security to Online Boutique in the Service Mesh setup, by adding predefined fine granular AuthorizationPolicies
, one per app:
If you run the following command you could see the AuthorizationPolicies
deployed:
Output similar to:
Note: in order to define these fine granular AuthorizationPolicies
we needed to create one ServiceAccount
per app too, instead of using the default
ServiceAccount
for all the apps.
You can verify that you can still access the Online Boutique website by clicking on this URL:
By navigating to the Anthos > Security page in your Google Cloud Console, you can see that Service access control is enabled in the Online Boutique namespace:
Deploy Online Boutique behind an Istio’s ingress gateway
To follow Istio’s best practice, let’s protect our Online Boutique’s apps behind and Istio’s Ingress Gateway.
Let’s deploy an Istio’s Ingress Gateway:
Now, let’s update the Online Boutique deployment in order to have the frontend
app behind the Ingress Gateway:
If you wait a little bit, when the Pods
are deployed, you can access the Online Boutique website via the Ingress Gateway now, by clicking on this URL:
By navigating to the Anthos > Service Mesh page in your Google Cloud Console, you can see the associated Topology now containing the Ingress Gateway:
By navigating to the Anthos > Security page in your Google Cloud Console, you can see that Service access control is enabled in the Ingress Gateway namespace too:
One last thing, not related to Online Boutique per say, but here is a quick win to add more security within your Service Mesh, by adding STRICT
mTLS for the communication between your apps in the Servie Mesh:
By navigating to the Anthos > Security page in your Google Cloud Console, you can see that mTLS status is enabled in your Service Mesh:
Deploy Online Boutique via Config Sync, in a GitOps way
Config Sync is a GitOps tool that you could leverage in your GKE cluster, which supports Helm chart to sync from an Helm registry to your GKE cluster, let’s see how you can accomplish this.
First, enable Config Sync on your GKE cluster:
Wait for Config Sync to be successfully enabled on your GKE cluster (Status
as NOT_CONFIGURED
):
Then, deploy the RootSync
configuration to sync this Helm chart in your GKE cluster:
By running the following command, you can see all the 73 resources synced from the Online Boutique Helm chart by Config Sync:
Output similar to:
Conclusion
The Online Boutique’s Helm chart allows to deploy either the default basic setup as well as more advanced, complex and secure setup with Service Mesh and Config Sync (GitOps).
We just saw how you can deploy Online Boutique with its fine granular NetworkPolicies
, Sidecars
, ServiceAccounts
and AuthorizationPolicies
. We also saw how you can expose the Online Boutique’s frontend
app via an Istio Ingress Gateway.
You can take inspiration of this to improve your own Security Posture with your own workloads.
More examples
You could also find advanced scenarios leveraging this Helm chart with these blogs below:
Hope you enjoyed that one, happy sailing, cheers!