Add Cloud Armor in front of this deployed demo

[mathieu-benoit]

Document the way to setup Cloud Armor in front of the public endpoint of this demo onlineboutique.dev.

What's in this PR:

• Document the steps do deploy the release-cluster part with more automation with gcloud
• Add BackendConfig to bind Cloud Armor to the Ingress
• Add FrontendConfig to bind the SSL Policy and redirect http to https
• Update Ingress's apiVersion from apiVersion: networking.k8s.io/v1beta1 to networking.k8s.io/v1 to avoid future breaking change because deprecation with GKE 1.22
• Remove the frontend-nodeport.yaml because it's not anymore a requirement, the default ClusterIP one is sufficient/working now.
• To avoid to have another Public IP, do a kubectl delete svc frontend-external in the process too
• Not related, fix a typo in the Memorystore (redis) doc.

Next steps:

• Test on a personal GKE cluster (see comment below with details information about the tests)
• Validate with the team about their thoughts and feedback
• If validated, apply this to onlineboutique.dev
• Eventually, port this to BoA too, to be consistent

[github-actions]

🚲 PR staged at http://104.154.87.241

[github-actions]

🚲 PR staged at http://104.154.87.241

[github-actions]

🚲 PR staged at http://104.154.87.241

[github-actions]

🚲 PR staged at http://104.154.87.241

[github-actions]

🚲 PR staged at http://104.154.87.241

[mathieu-benoit]

Tests conducted:

Bash commands to test this PR...

PROJECT_ID=FIXME
gcloud config set project $PROJECT_ID
kubectl create ns onlineboutique
kubectl apply -f release/kubernetes-manifests.yaml -n onlineboutique
gcloud compute addresses create online-boutique-ip --global
PUBLIC_IP=$(gcloud compute addresses describe online-boutique-ip \
    --global \
    --format "value(address)")
HOST_NAME="onlineboutique.endpoints.${PROJECT_ID}.cloud.goog"
cat <<EOF > dns-spec.yaml
swagger: "2.0"
info:
  description: "Cloud Endpoints DNS"
  title: "Cloud Endpoints DNS"
  version: "1.0.0"
paths: {}
host: "${HOST_NAME}"
x-google-endpoints:
- name: "${HOST_NAME}"
  target: "${PUBLIC_IP}"
EOF
gcloud endpoints services deploy dns-spec.yaml
SECURITY_POLICY_NAME=online-boutique-security-policy
gcloud compute security-policies create $SECURITY_POLICY_NAME \
    --description "Block XSS attacks"
gcloud compute security-policies rules create 1000 \
    --security-policy $SECURITY_POLICY_NAME \
    --expression "evaluatePreconfiguredExpr('xss-stable')" \
    --action "deny-403" \
    --description "XSS attack filtering"
gcloud compute security-policies rules create 12345 \
    --security-policy $SECURITY_POLICY_NAME \
    --expression "evaluatePreconfiguredExpr('cve-canary')" \
    --action "deny-403" \
    --description "CVE-2021-44228 and CVE-2021-45046"
gcloud compute security-policies update $SECURITY_POLICY_NAME \
    --enable-layer7-ddos-defense
gcloud compute security-policies update $SECURITY_POLICY_NAME \
    --log-level=VERBOSE
SSL_POLICY_NAME=online-boutique-ssl-policy
gcloud compute ssl-policies create $SSL_POLICY_NAME \
    --profile COMPATIBLE  \
    --min-tls-version 1.0
sed -i "s,onlineboutique.dev,${HOST_NAME},g" .github/release-cluster/managed-cert.yaml
kubectl apply -f .github/release-cluster/ -n onlineboutique

[github-actions]

🚲 PR staged at http://104.154.87.241

[github-actions]

🚲 PR staged at http://104.154.87.241

[mathieu-benoit]

Ready for your review and comments, thanks.

[github-actions]

🚲 PR staged at http://104.154.87.241

[NimJay]

Thanks so much for creating this pull-request. And apologies for the late review.
I think using Cloud Armor is a good idea — we would be dog-fooding yet another GCP product! :)

Warning: I have added a commit to the mathieu-benoit/cloud-armor-release-cluster branch, with some wording changes.
So you may want to git pull from your end.

Question:
See hack/README.md where we've documented the release process.
Step 10 consists of applying ./release/kubernetes-manifests.yaml to our deployment GKE cluster.
Do you think we should add a step between step 10 and step 11 similar to:

11. Delete unused resources.

kubectl delete service frontend-external
kubectl delete deployment loadgenerator

I am currently testing everything out in my own GCP project (i.e., still reviewing).

[mathieu-benoit]

Thanks for the wording changes @NimJay.
For your suggestion, I think that's a good idea. Why not making a disclaimer/note at the beginning to point/mention this release process page/doc by saying "assumption that the release process has been applied" or something like this? So without duplicating any steps/commands, just pointing to the existing one?
I can do the commit/change about that, but just making sure with you about the approach.

[NimJay]

Ah, that's a good idea.
I like the idea of not duplicating instructions.
Go for it. :)

[NimJay]

Just finished testing this on my own cluster and domain.
See deletemenow.peachytools.com (which I'll take down once this PR is merged).
Cloud Armor was applied:

I didn't test Cloud Armor itself — but I trust that it works.
I left 2 comments.
They're minor so I'll approve this.

Thanks again for doing this, @mathieu-benoit! And thanks for the very details PR description. It made the changes easy to review. 👏

I'll apply the changes (set up Cloud Armor) to onlineboutique.dev as soon as this is merge. :)

[github-actions]

🚲 PR staged at http://104.154.87.241

[mathieu-benoit]

Thanks for the review and comments @NimJay, let me know if there is anything else.

[NimJay]

I just applied the changes to the onlineboutique.dev cluster (online-boutique-release).
For some reason, the online-boutique-security-policy has "0 targets".
I'll give it some time and check back in a bit.

[NimJay]

Update on Investigation

@mathieu-benoit and I just investigated a bit.

The frontend-ingress is still connected to the old frontend-nodeport:

kubectl describe ingress
Name:             frontend-ingress
Labels:           <none>
Namespace:        default
Address:          35.244.250.164
Default backend:  frontend-nodeport:80 (<error: endpoints "frontend-nodeport" not found>)

which I had deleted using:

kubectl delete Service frontend-nodeport

after I applied the new manifests from the ./github/release-cluster/ folder.

But we just reapplied the old frontend-nodeport.yaml file.
And now we see that the Cloud Armor online-boutique-security-policy has "1 target".

[mathieu-benoit]

Found out the issue: because of the update of the ingress to v1, I haven't set the defaultBakend field. The issue was not there on a brand new GKE cluster we tested, but because the Ingress of the live cluster of onlineboutique.dev was pointing to the deleted frontendservice-nodeport, it raised that issue.

All good now, #698 is fixing the issue.