Update Blog “federating-spire-on-hpe-greenlake-for-private-cloud-enterprise”

Author: akanshasajimon

content/blog/federating-spire-on-hpe-greenlake-for-private-cloud-enterprise.md

@@ -120,7 +120,9 @@ This patch will register your ingress-gateway pod into the server.
 kubectl patch deployment istio-ingressgateway -n istio-system -p '{"spec":{"template":{"metadata":{"labels":{"spiffe.io/spire-managed-identity": "true"}}}}}' 
 ```
 
-### 2.3.3 After patching, confirm the working of your ingress-gateway pod, istiod and all their containers. 
+### 2.3.3 Check your work
+
+After patching, confirm that your ingress-gateway pod, istiod and all their containers work.
 
 ```shellsession
 Cluster1:~ # kubectl get po -n istio-system 
@@ -138,17 +140,17 @@ istiod-d5bc8669c-thbpj                 1/1     Running   0          37d
 
 # Step 3. Federating SPIRE
 
-## 3.1 Expose SPIRE server bundle endpoint. 
+## 3.1 Expose SPIRE server bundle endpoint
 
 Assign an external IP to your spire-server-bundle-endpoint service on each cluster.  
 
-SPIFFE ( *Secure Production Identity Framework For Everyone*) is a specification for implementing identity for workloads, and SPIRE is the code that implements this specification in practice. A SPIFFE bundle is a resource that contains the public key material needed to authenticate credentials from a particular trust domain. A SPIFFE bundle endpoint is a resource (represented by a URL) that serves a copy of a SPIFFE bundle for a trust domain. SPIFFE control planes may both expose and consume these endpoints to transfer bundles between themselves, thereby achieving federation. We use the SPIRE server to host the “spire-server-bundle-endpoint” service that serves the SPIFFE bundle to an external Spire agent of a different trust domain.  
+SPIFFE (*Secure Production Identity Framework For Everyone*) is a specification for implementing identity for workloads, and SPIRE is the code that implements this specification in practice. A SPIFFE bundle is a resource that contains the public key material needed to authenticate credentials from a particular trust domain. A SPIFFE bundle endpoint is a resource (represented by a URL) that serves a copy of a SPIFFE bundle for a trust domain. SPIFFE control planes may both expose and consume these endpoints to transfer bundles between themselves, thereby achieving federation. The SPIRE server is used to host the “spire-server-bundle-endpoint” service that serves the SPIFFE bundle to an external Spire agent of a different trust domain.  
 
-We use MetalLB to assign the IP for this service. MetalLB hooks into your Kubernetes cluster and provides a network load-balancer implementation. In short, it allows you to create Kubernetes services of type LoadBalancer in clusters that don’t run on a cloud provider, and thus cannot simply hook into paid products to provide load balancers. 
+MetalLB is used to assign the IP for this service. MetalLB hooks into your Kubernetes cluster and provides a network load-balancer implementation. In short, it allows you to create Kubernetes services of type LoadBalancer in clusters that don’t run on a cloud provider, and thus cannot simply hook into paid products to provide load balancers. 
 
 Follow this [link](https://metallb.universe.tf/configuration/_advanced_ipaddresspool_configuration/#controlling-automatic-address-allocation) to set up an automatic address allocation for all services that have type external IP. 
 
-Ours looks something like this: 
+The configuration should now look something like this:
 
 ```shellsession
 Cluster1:~ # kubectl get svc -n spire 
@@ -170,7 +172,7 @@ spire-server-bundle-endpoint               LoadBalancer   10.104.151.184  172.16
 
 The Cluster Federated Trust Domain CRD is used to federate the clusters with each other.  
 
-It requires the following configurations: 
+It requires the following federation configurations: 
 
 ### Cluster Federated Trust Domain:
 
@@ -201,7 +203,7 @@ Cluster2:~ # kubectl exec -n spire -c spire-server deployment/spire-server -- /o
 
 Doing a cat command of the bundles reveals the keys to be copied into the trust domain bundle field.  
 
-After the Bundle endpoint URL and the TrustDomainBundle fields are configured and applied, check the status of the spire pods to make sure they are running and check the logs of the spire-server to verify successful federation.
+After the Bundle endpoint URL and the TrustDomainBundle fields are configured and applied, check the status of the  SPIRE pods to make sure they are running and check the logs of the spire-server to verify successful federation.
 
 ```shellsession
 Cluster1:~ # kubectl logs -n spire -c spire-server spire-server-574474c7dc-gbzl6 
@@ -215,27 +217,27 @@ Cluster2:~ # kubectl logs -n spire -c spire-server spire-server-574474c7dc-2bfcx
 
 ![Cluster-2 Logs](/img/table4.png)
 
-# Step 4. Deploying a sample application :
+# Step 4. Deploying a sample application
 
-Now that SPIRE is federated and communication across clusters can be facilitated, let us deploy a sample application that verifies this functionality.   
+Now that SPIRE is federated and communication across clusters can be facilitated, here's how you can deploy a sample application that verifies this functionality.   
 
 ## 4.1 Deploy a resource in Cluster-1
 
-In Cluster 1, apply a new ClusterSpiffeID called federated that registers resources with the label **spiffe.io/spire-managed-identity=curl-greeter** that can be federated with cluster2. Create a resource called curl-greeter that has the label: **spiffe.io/spire-managed-identity=curl-greeter** and annotation: **inject.istio.io/templates=sidecar, spire** 
+In Cluster 1, apply a new ClusterSpiffeID called ***federated*** that registers resources with the label **spiffe.io/spire-managed-identity=curl-greeter** that can be federated with cluster2. Create a resource called ***curl-greeter*** that has the label: **spiffe.io/spire-managed-identity=curl-greeter** and annotation: **inject.istio.io/templates=sidecar, spire** 
 
 ```shellsession
 kubectl run curl-greeter --image=radial/busyboxplus:curl --labels="spiffe.io/spire-managed-identity=curl-greeter" --overrides='{ "apiVersion": "v1", "spec": { "template": {"metadata": {"annotations": { "inject.istio.io/templates":"sidecar,spire" } } }}}' -i --tty 
 ```
 
 ## 4.2 Deploy Bookinfo Sample Application in Cluster-2
 
-In Cluster 2, apply a new ClusterSpiffeID called federated that registers resources with the label **spiffe.io/spire-managed-identity=spire** that can be federated with cluster1. Apply the bookinfo sample application manifest. 
+In Cluster 2, apply a new ClusterSpiffeID called ***federated*** that registers resources with the label **spiffe.io/spire-managed-identity=spire** that can be federated with cluster1. Apply the bookinfo sample application manifest. 
 
 ```shellsession
 kubectl apply -f services/istio/release-1.17/bookinfo.yaml 
 ```
 
-## 4.3 Check if all the resources created are up and running:
+## 4.3 Check if all the resources created are up and running
 
 ```shellsession
 Cluster1:~ # kubectl get po 
@@ -260,7 +262,7 @@ reviews-v3-6dbfcc6d89-zn9tw         2/2     Running   0      
 
 ## 4.4 Check that the workload identity was issued by SPIRE
 
-Spire Certificate at Curl-Greeter 
+SPIRE certificate at Curl-Greeter 
 
 ```shellsession
 Cluster1:~ # istioctl proxy-config secret curl-greeter -o json | jq -r \ 
@@ -274,7 +276,9 @@ Cluster1:~ # openssl x509 -in chain.pem -text | grep SPIRE
 
 *Note: Similarly, certificates for other pods can be checked.* 
 
-## 4.5 Create a secret to hold bookinfo product page credentials like this: 
+## 4.5 Create a secret
+
+Create a secret to hold bookinfo product page credentials like this: 
 
 ```shellsession
 kubectl create -n istio-system secret generic bookinfo-credential \ 
@@ -302,13 +306,13 @@ kubectl exec -n spire -c spire-server deployment/spire-server -- /opt/spire/bin/
 
 *Note: Copy the ca cert under the cluster1.demo section into a new file bookinfo.ca.cert.* 
 
-Apply the gateway configuration for the bookinfo application found here: (It uses the istio-ingress gateway) 
+Apply the gateway configuration for the bookinfo application found [here](https://github.com/cxteamtrials/caas-trials-content/blob/main/services/istio/release-1.17/samples/bookinfo-gateway.yaml): (It uses the istio-ingress gateway) 
 
 ```shellsession
 kubectl apply -f services/istio/release-1.17/bookinto-gateway.yaml
 ```
 
-## 4.6 Generate traffic to the sample application on cluster2 from the curl greeter on cluster 1:  
+## 4.6 Generate traffic to the sample application on cluster2 from the curl greeter on cluster 1
 
 Curl Command at Cluster 1 (IP addr: istio-ingress-gateway external ip) 
 
@@ -430,12 +434,12 @@ kubectl exec -n spire -c spire-server deployment/spire-server -- /opt/spire/bin/
 
 *Note: Copy the ca cert under the cluster2.demo section into a new file bookinfo.ca.cert.* 
 
-## 4.7 Visualize using Service Mesh: 
+## 4.7 Visualize using Service Mesh
 
-Using the Kiali dashboard, observing the graphs of generated traffic. 
+Using the Kiali dashboard, observe the graphs of generated traffic. 
 
 The graph below shows services communication, and the locks symbolize mTls protocol. 
 
 ![mTLS Graph](/img/mtls.png)
 
-The goal of this blog was to guide you through federating SPIRE across two Kubernetes clusters deployed on HPE GreenLake for Private Cloud Enterprise by creating a cluster federated trust domain and federated ClusterSpiffeIDs for your sample application workloads as well as to help you visualize your service mesh through Kiali Dashboard.
+The goal of this blog post was to guide you through federating SPIRE across two Kubernetes clusters deployed on HPE GreenLake for Private Cloud Enterprise. It shows you how to do this by creating a cluster federated trust domain and federated ClusterSpiffeIDs for your sample application workloads and **then helps** you visualize your service mesh through Kiali Dashboard