Changing module strucutre

manifests/modules/security/secrets-manager/secret-provider-class.yaml

@@ -0,0 +1,11 @@
+apiVersion: secrets-store.csi.x-k8s.io/v1
+kind: SecretProviderClass
+metadata:
+  name: catalog-spc
+  namespace: catalog
+spec:
+  provider: aws
+  parameters:
+    objects: |
+        - objectName: "catalog-secret"
+          objectType: "secretsmanager"

website/docs/security/secrets-management/exploring-secrets.md

@@ -66,53 +66,3 @@ With the above Pod specification, the following will occur:
 
 * value for the username key in the database-credentials Secret is stored in the file `/etc/data/DATABASE_USER` within the Pod
 * value for the password key is stored in the file `/etc/data/DATABASE_PASSWORD`
-
-### Exploring the catalog Pod
-
-The `catalog` deployment in the `catalog` Namespace accesses the following database values from the catalog-db secret via environment variables:
-
-* `DB_USER`
-* `DB_PASSWORD`
-
-```bash
-$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .env'
-
-- name: DB_USER
-  valueFrom:
-    secretKeyRef:
-      key: username
-      name: catalog-db
-- name: DB_PASSWORD
-  valueFrom:
-    secretKeyRef:
-      key: password
-      name: catalog-db
-- name: DB_NAME
-  valueFrom:
-    configMapKeyRef:
-      key: name
-      name: catalog
-- name: DB_READ_ENDPOINT
-  valueFrom:
-    secretKeyRef:
-      key: endpoint
-      name: catalog-db
-- name: DB_ENDPOINT
-  valueFrom:
-    secretKeyRef:
-      key: endpoint
-      name: catalog-db
-```
-
-Upon exploring the `catalog-db` Secret we can see that it is only encoded with base64 which can be easily decoded as follows hence making it difficult for the secrets manifests to be part of the GitOps workflow.
-
-```file
-manifests/base-application/catalog/secrets.yaml
-```
-
-```bash
-$ kubectl -n catalog get secrets catalog-db --template {{.data.username}} | base64 -d
-catalog_user%                                                                                                                                                                                                   
-$ kubectl -n catalog get secrets catalog-db --template {{.data.password}} | base64 -d
-default_password% 
-```

website/docs/security/secrets-management/sealed-secrets/installing-sealed-secrets.md

@@ -1,6 +1,6 @@
 ---
 title: "Installing Sealed Secrets"
-sidebar_position: 62
+sidebar_position: 72
 ---
 
 The `kubeseal` CLI is used to interact with the sealed secrets controller, and has already been installed in Cloud9.

website/docs/security/secrets-management/sealed-secrets/managing-sealing-keys.md

@@ -1,6 +1,6 @@
 ---
 title: "Managing the Sealing Key"
-sidebar_position: 64
+sidebar_position: 74
 ---
 
 The only way to decrypt the encrypted data within a SealedSecret is with the sealing key that is managed by the controller. There could be situations where you are trying to restore the original state of a cluster after a disaster or you want to leverage GitOps workflow to deploy the Kubernetes resources, including SealedSecrets, from a Git repository and create a new EKS cluster. The controller deployed in the new EKS cluster must use the same sealing key to be able to unseal the SealedSecrets.

website/docs/security/secrets-management/sealed-secrets/sealing-secrets.md

@@ -1,8 +1,58 @@
 ---
 title: "Sealing your Secrets"
-sidebar_position: 63
+sidebar_position: 73
 ---
 
+### Exploring the catalog Pod
+
+The `catalog` deployment in the `catalog` Namespace accesses the following database values from the catalog-db secret via environment variables:
+
+* `DB_USER`
+* `DB_PASSWORD`
+
+```bash
+$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .env'
+
+- name: DB_USER
+  valueFrom:
+    secretKeyRef:
+      key: username
+      name: catalog-db
+- name: DB_PASSWORD
+  valueFrom:
+    secretKeyRef:
+      key: password
+      name: catalog-db
+- name: DB_NAME
+  valueFrom:
+    configMapKeyRef:
+      key: name
+      name: catalog
+- name: DB_READ_ENDPOINT
+  valueFrom:
+    secretKeyRef:
+      key: endpoint
+      name: catalog-db
+- name: DB_ENDPOINT
+  valueFrom:
+    secretKeyRef:
+      key: endpoint
+      name: catalog-db
+```
+
+Upon exploring the `catalog-db` Secret we can see that it is only encoded with base64 which can be easily decoded as follows hence making it difficult for the secrets manifests to be part of the GitOps workflow.
+
+```file
+manifests/base-application/catalog/secrets.yaml
+```
+
+```bash
+$ kubectl -n catalog get secrets catalog-db --template {{.data.username}} | base64 -d
+catalog_user%                                                                                                                                                                                                   
+$ kubectl -n catalog get secrets catalog-db --template {{.data.password}} | base64 -d
+default_password% 
+```
+
 Let's create a new secret `catalog-sealed-db`. We'll create a new file `new-catalog-db.yaml` with the same keys and values as the `catalog-db` Secret.
 
 ```file

website/docs/security/secrets-management/sealed-secrets/working.md

@@ -1,6 +1,6 @@
 ---
 title: "Sealed Secrets for Kubernetes"
-sidebar_position: 61
+sidebar_position: 71
 ---
 
 Sealed Secrets is composed of two parts:

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

@@ -1,6 +1,6 @@
 ---
 title: "Storing secrets in AWS Secrets Manager"
-sidebar_position: 63
+sidebar_position: 62
 ---
 
 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/index.md

@@ -21,7 +21,7 @@ You can view the Terraform that applies these changes [here](https://github.com/
 
 :::
 
-AWS Secrets Manager (Secrets Manager) allows you to easily rotate, manage, and retrieve sensitive data such as credentials, API keys, certificates, among others. You can use AWS Secrets and Configuration Provider (ASCP) for Kubernetes Secrets Store CSI Driver to mount secrets stored in Secrets Manager as volumes in Kubernetes Pods.
+[AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) allows you to easily rotate, manage, and retrieve sensitive data such as credentials, API keys, certificates, among others. You can use [AWS Secrets and Configuration Provider (ASCP)](https://github.com/aws/secrets-store-csi-driver-provider-aws) for [Kubernetes Secrets Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/) to mount secrets stored in Secrets Manager as volumes in Kubernetes Pods.
 
 With the ASCP, you can store and manage your secrets in Secrets Manager and then retrieve them through your workloads running on Amazon EKS. You can use IAM roles and policies to limit access to your secrets to specific Kubernetes Pods in a cluster. The ASCP retrieves the Pod identity and exchanges the identity for an IAM role. ASCP assumes the IAM role of the Pod, and then it can retrieve secrets from Secrets Manager that are authorized for that role.
 

website/docs/security/secrets-management/secrets-manager/validate-cluster-resources.md

@@ -0,0 +1,102 @@
+---
+title: "Validating AWS Secrets and Configuration Provider (ASCP)"
+sidebar_position: 61
+---
+
+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.
+
+Lets then, validate if the addons deployed.
+
+Check the Secret Store CSI drive `DaemonSet` and respective `Pods`.
+
+```bash
+$ kubectl -n secrets-store-csi-driver get pods,daemonsets -l app=secrets-store-csi-driver
+NAME                                                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
+daemonset.apps/csi-secrets-store-secrets-store-csi-driver   3         3         3       3            3           kubernetes.io/os=linux   3m57s
+
+NAME                                                   READY   STATUS    RESTARTS   AGE
+pod/csi-secrets-store-secrets-store-csi-driver-bzddm   3/3     Running   0          3m57s
+pod/csi-secrets-store-secrets-store-csi-driver-k7m6c   3/3     Running   0          3m57s
+pod/csi-secrets-store-secrets-store-csi-driver-x2rs4   3/3     Running   0          3m57s
+```
+
+Check the CSI Secrets Store Provider for AWS driver `DaemonSet` and respective `Pods`.
+
+```bash
+$ kubectl -n kube-system get pods,daemonset -l "app=secrets-store-csi-driver-provider-aws"  
+NAME                                                   DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
+daemonset.apps/secrets-store-csi-driver-provider-aws   3         3         3       3            3           kubernetes.io/os=linux   2m3s
+
+NAME                                              READY   STATUS    RESTARTS   AGE
+pod/secrets-store-csi-driver-provider-aws-4jf8f   1/1     Running   0          2m2s
+pod/secrets-store-csi-driver-provider-aws-djtf5   1/1     Running   0          2m2s
+pod/secrets-store-csi-driver-provider-aws-dzg9r   1/1     Running   0          2m2s
+```
+
+### Exploring the catalog Pod
+
+The `catalog` deployment in the `catalog` Namespace accesses the following database values from the catalog-db secret via environment variables:
+
+* `DB_USER`
+* `DB_PASSWORD`
+
+```bash
+$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .env'
+
+- name: DB_USER
+  valueFrom:
+    secretKeyRef:
+      key: username
+      name: catalog-db
+- name: DB_PASSWORD
+  valueFrom:
+    secretKeyRef:
+      key: password
+      name: catalog-db
+- name: DB_NAME
+  valueFrom:
+    configMapKeyRef:
+      key: name
+      name: catalog
+- name: DB_READ_ENDPOINT
+  valueFrom:
+    secretKeyRef:
+      key: endpoint
+      name: catalog-db
+- name: DB_ENDPOINT
+  valueFrom:
+    secretKeyRef:
+      key: endpoint
+      name: catalog-db
+```
+
+Upon exploring the `catalog-db` Secret we can see that it is only encoded with base64 which can be easily decoded as follows hence making it difficult for the secrets manifests to be part of the GitOps workflow.
+
+```file
+manifests/base-application/catalog/secrets.yaml
+```
+
+```bash
+$ kubectl -n catalog get secrets catalog-db --template {{.data.username}} | base64 -d
+catalog_user%                                                                                                                                                                                                   
+$ kubectl -n catalog get secrets catalog-db --template {{.data.password}} | base64 -d
+default_password% 
+```
+
+You should also see that we already have created a *SecretProviderClass*, which is a namespaced custom resource that's used provide driver configurations and specific parameters to the your secrets in AWS Secrets Manger via CSI driver.
+
+```bash
+$ kubectl -n catalog get secretproviderclass -o yaml
+
+apiVersion: secrets-store.csi.x-k8s.io/v1
+kind: SecretProviderClass
+metadata:
+  name: catalog-spc
+  namespace: catalog
+spec:
+  provider: aws
+  parameters:
+    objects: |
+        - objectName: "catalog-secret"
+          objectType: "secretsmanager"
+```