Review

manifests/modules/security/secrets-manager/.workshop/manifetst/cluster-secret-store.yaml

@@ -0,0 +1,14 @@
+apiVersion: external-secrets.io/v1beta1
+kind: ClusterSecretStore
+metadata:
+  name: "cluster-secret-store"
+spec:
+  provider:
+    aws:
+      service: SecretsManager
+      region: $AWS_REGION
+      auth:
+        jwt:
+          serviceAccountRef:
+            name: "external-secrets-sa"
+            namespace: "external-secrets"

manifests/modules/security/secrets-manager/.workshop/manifetst/config.env

@@ -0,0 +1 @@
+AWS_REGION

manifests/modules/security/secrets-manager/.workshop/manifetst/kustomization.yaml

@@ -0,0 +1,5 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+resources:
+- secret-provider-class.yaml
+- cluster-secret-store.yaml

manifests/modules/security/secrets-manager/.workshop/terraform/addon.tf

@@ -95,29 +95,22 @@ resource "kubernetes_annotations" "catalog-sa" {
   force = true
 }
 
-resource "kubernetes_manifest" "cluster_secretstore" {
-  manifest = {
-    "apiVersion" = "external-secrets.io/v1beta1"
-    "kind"       = "ClusterSecretStore"
-    "metadata" = {
-      "name" = "cluster-secret-store"
-    }
-    "spec" = {
-      "provider" = {
-        "aws" = {
-          "service" = "SecretsManager"
-          "region"  = "${data.aws_region.current.name}"
-          "auth" = {
-            "jwt" = {
-              "serviceAccountRef" = {
-                "name"      = "external-secrets-sa"
-                "namespace" = "external-secrets"
-              }
-            }
-          }
-        }
-      }
-    }
-  }
+resource "kubectl_manifest" "cluster_secretstore" {
+  yaml_body  = <<YAML
+apiVersion: external-secrets.io/v1beta1
+kind: ClusterSecretStore
+metadata:
+  name: "cluster-secret-store"
+spec:
+  provider:
+    aws:
+      service: SecretsManager
+      region: "${data.aws_region.current.name}"
+      auth:
+        jwt:
+          serviceAccountRef:
+            name: "external-secrets-sa"
+            namespace: "external-secrets"
+YAML
   depends_on = [module.external_secrets]
-}
+}

manifests/modules/security/secrets-manager/external-secrets/external-secret.yaml

@@ -10,4 +10,4 @@ spec:
     kind: ClusterSecretStore
   dataFrom:
   - extract:
-      key: "eks-workshop/catalog-secret"
+      key: "eks-workshop/catalog-secret"

website/docs/security/secrets-management/secrets-manager/ascp.md

@@ -1,9 +1,9 @@
 ---
 title: "AWS Secrets and Configuration Provider (ASCP)"
-sidebar_position: 61
+sidebar_position: 62
 ---
 
-If you ran the `prepare-environment` script detailed in the [previous step](./index.md), it has already installed the AWS Secrets and Configuration Provider (ASCP) for the Kubernetes Secrets Store CSI Driver that's required for this lab.
+If you ran the `prepare-environment` script detailed in a [previous step](./index.md), it has already installed the AWS Secrets and Configuration Provider (ASCP) for the Kubernetes Secrets Store CSI Driver that's required for this lab.
 
 Lets then, validate if the addons deployed.
 
@@ -39,7 +39,7 @@ You should also see that we already have created a SecretProviderClass, which is
 manifests/modules/security/secrets-manager/secret-provider-class.yaml
 ```
 
-In the above resource, we have two main configurations that we should be focusing.
+In the above resource, you have two main configurations that you should be focusing.
 
 The *objects* parameter, which is pointing to a secret named as `eks-workshop/catalog-secret` that we will store in AWS Secrets Manager in the next step. Note that we are using [jmesPath](https://jmespath.org/), to extract a specific key-value from the secret that is JSON-formatted.
 
@@ -55,7 +55,7 @@ $ kubectl get secretproviderclass -n catalog catalog-spc -o yaml | yq '.spec.par
       objectAlias: password
 ```
 
-And the *secretObjects*, that will create and/or sync a Kubernetes secret with the data from the secret stored in AWS Secrets Manager. This means that when mounted to a Pod, the SecretProviderClass, will create a Kubernetes Secret, if it doesn't exist yet, and sync the values stored in AWS Secrets Manager with this Kubernetes Secret, in our case, it will be called as `catalog-secret`.
+And the *secretObjects*, that will create and/or sync a Kubernetes secret with the data from the secret stored in AWS Secrets Manager. This means that when mounted to a Pod, the SecretProviderClass, will create a Kubernetes Secret, if it doesn't exist yet, and sync the values stored in AWS Secrets Manager with this Kubernetes Secret, in our case, it is named `catalog-secret`.
 
 ```bash
 $ kubectl get secretproviderclass -n catalog catalog-spc -o yaml | yq '.spec.secretObjects'
@@ -68,5 +68,3 @@ $ kubectl get secretproviderclass -n catalog catalog-spc -o yaml | yq '.spec.sec
   secretName: catalog-secret
   type: Opaque
 ```
-
-Lets move on, and store our credentials on AWS Secrets Manager.

website/docs/security/secrets-management/secrets-manager/create-secret.md

@@ -1,6 +1,6 @@
 ---
 title: "Storing secrets in AWS Secrets Manager"
-sidebar_position: 62
+sidebar_position: 61
 ---
 
 To store a secret in AWS Secrets Manager, you can either use the AWS Console or the AWS CLI. We will cover both scenarios below.

website/docs/security/secrets-management/secrets-manager/external-secrets.md

@@ -129,4 +129,6 @@ $ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.co
     secretKeyRef:
       key: password
       name: catalog-external-secret
-```
+```
+
+**In conclusion, there is no best option on choosing between AWS Secrets and Configuration Provider (ASCP) vs. External Secrets Operator (ESO) in order to store your secrets on AWS Secrets Manager. Both tools have their specific advantages, for example, ASCP can help you avoid exposing secrets as environment variables, mounting them as volumes directly from AWS Secrets Manager into a Pod, the drawback is the need to manage those volumes. In the other hand ESO makes easier the Kubernetes Secrets lifecycle management, having also a cluster wide SecretStore, however it doesn't allow you to use Secrets as volumes. It all depends on your use case, and having both can bring you a lot more flexibility and security with Secrets Management.**

website/docs/security/secrets-management/secrets-manager/mounting-secrets.md

@@ -3,7 +3,7 @@ title: "Mounting AWS Secrets Manager secret on Kubernetes Pod"
 sidebar_position: 63
 ---
 
-Now that you have a secret stored in AWS Secrets Manager, let's mount it inside the Pod, but first you should take a look on the `catalog` Deployment and the existing Secrets in the `catalog` Namespace.
+Now that you have a secret stored in AWS Secrets Manager and synced with a Kubernetes Secret, let's mount it inside the Pod, but first you should take a look on the `catalog` Deployment and the existing Secrets in the `catalog` Namespace.
 
 The `catalog` Deployment accesses the following database credentials from the `catalog-db` secret via environment variables:
 
@@ -73,7 +73,31 @@ $ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.co
   name: tmp-volume
 ```
 
-Also, the Environment Variables are now being consumed from a new Secret, called `catalog-secret` that didn't exist earlier, and it was created by the SecretProviderClass via CSI Secret Store driver.
+Mounted Secrets are a good way to have sensitive information available as a file inside the filesystem of one or more of the Pod's containers, some benefits are not exposing the value of the secret as environment variables and when a volume contains data from a Secret, and that Secret is updated, Kubernetes tracks this and updates the data in the volume.
+
+You can take a look on the contents of the mounted Secret inside your Pod.
+
+```bash
+$ kubectl -n catalog exec -ti $(kubectl -n catalog get pods -l app.kubernetes.io/component=service -o name --no-headers) -- /bin/bash
+
+[appuser@catalog-76c48477ff-d9dfh ~]$ ls /etc/catalog-secret/ 
+eks-workshop_catalog-secret  password  username
+
+[appuser@catalog-76c48477ff-d9dfh ~]$ ls /etc/catalog-secret/ | while read SECRET; do cat /etc/catalog-secret/$SECRET; echo; done
+{"username":"catalog_user", "password":"default_password"}
+default_password
+catalog_user
+
+[appuser@catalog-76c48477ff-d9dfh ~]$ exit
+```
+
+You could verify that there are 3 files in the mountPath `/etc/catalog-secret`. `
+1. `eks-workshop_catalog-secret`: With the unformated value of the secret.
+2. `password`: password jmesPath filtered and formatted value.
+3. `username`: username jmesPath filtered and formatted value.
+
+
+Also, the Environment Variables are now being consumed from the new Secret, `catalog-secret` that didn't exist earlier, and it was created by the SecretProviderClass via CSI Secret Store driver.
 
 ```bash
 $ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .env'