diff --git a/manifests/modules/security/secrets-manager/.workshop/terraform/addon.tf b/manifests/modules/security/secrets-manager/.workshop/terraform/addon.tf
new file mode 100644
index 000000000..95b9a330f
--- /dev/null
+++ b/manifests/modules/security/secrets-manager/.workshop/terraform/addon.tf
@@ -0,0 +1,116 @@
+module "secrets-store-csi-driver" {
+  source = "github.com/aws-ia/terraform-aws-eks-blueprints?ref=v4.32.1//modules/kubernetes-addons/secrets-store-csi-driver"
+
+  helm_config = {
+    version = "1.3.4"
+    set = [{
+      name  = "syncSecret.enabled"
+      value = true
+      },
+      {
+        name  = "enableSecretRotation"
+        value = true
+    }]
+  }
+
+  addon_context = local.addon_context
+}
+
+module "secrets_store_csi_driver_provider_aws" {
+  source = "github.com/aws-ia/terraform-aws-eks-blueprints?ref=v4.32.1//modules/kubernetes-addons/csi-secrets-store-provider-aws"
+
+  helm_config = {
+    version = "0.3.4"
+  }
+
+  addon_context = local.addon_context
+}
+
+module "external_secrets" {
+  source = "github.com/aws-ia/terraform-aws-eks-blueprints?ref=v4.32.1//modules/kubernetes-addons/external-secrets"
+
+  helm_config = {
+    version = "0.9.5"
+  }
+
+  addon_context = local.addon_context
+}
+
+module "secrets_manager_role" {
+  source  = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"
+  version = "~> 5.30"
+
+  role_name_prefix = "${data.aws_eks_cluster.eks_cluster.id}-secrets-manager-"
+
+  role_policy_arns = {
+    policy = aws_iam_policy.secrets_manager.arn
+  }
+
+  oidc_providers = {
+    main = {
+      provider_arn               = "arn:${data.aws_partition.current.partition}:iam::${data.aws_caller_identity.current.account_id}:oidc-provider/${local.eks_oidc_issuer_url}"
+      namespace_service_accounts = ["catalog:catalog"]
+    }
+  }
+
+  tags = local.tags
+}
+
+resource "aws_iam_policy" "secrets_manager" {
+  name_prefix = "${data.aws_eks_cluster.eks_cluster.id}-secrets-manager-"
+  policy      = <<POLICY
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": [
+        "secretsmanager:GetSecretValue",
+        "secretsmanager:DescribeSecret"
+      ],
+      "Resource": "arn:${data.aws_partition.current.partition}:secretsmanager:${data.aws_region.current.name}:${data.aws_caller_identity.current.account_id}:secret:*"
+    },
+    {
+      "Effect": "Allow",
+      "Action": [
+        "kms:Decrypt"
+      ],
+      "Resource": "arn:${data.aws_partition.current.partition}:kms:${data.aws_region.current.name}:${data.aws_caller_identity.current.account_id}:key/*"
+    }
+  ]
+}
+POLICY
+}
+
+resource "kubernetes_annotations" "catalog-sa" {
+  api_version = "v1"
+  kind        = "ServiceAccount"
+  metadata {
+    name      = "catalog"
+    namespace = "catalog"
+  }
+  annotations = {
+    "eks.amazonaws.com/role-arn" = "${module.secrets_manager_role.iam_role_arn}"
+  }
+  force = true
+}
+
+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]
+}
\ No newline at end of file
diff --git a/manifests/modules/security/secrets-manager/cluster-secret-store.yaml b/manifests/modules/security/secrets-manager/cluster-secret-store.yaml
new file mode 100644
index 000000000..85e6a1596
--- /dev/null
+++ b/manifests/modules/security/secrets-manager/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"
\ No newline at end of file
diff --git a/manifests/modules/security/secrets-manager/external-secrets/deployment.yaml b/manifests/modules/security/secrets-manager/external-secrets/deployment.yaml
new file mode 100644
index 000000000..2f9552a49
--- /dev/null
+++ b/manifests/modules/security/secrets-manager/external-secrets/deployment.yaml
@@ -0,0 +1,21 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: catalog
+  namespace: catalog
+spec:
+  template:
+    spec:
+      containers:
+        - name: catalog
+          env:
+            - name: DB_USER
+              valueFrom:
+                secretKeyRef:
+                  name: catalog-external-secret
+                  key: username
+            - name: DB_PASSWORD
+              valueFrom:
+                secretKeyRef:
+                  name: catalog-external-secret
+                  key: password
\ No newline at end of file
diff --git a/manifests/modules/security/secrets-manager/external-secrets/external-secret.yaml b/manifests/modules/security/secrets-manager/external-secrets/external-secret.yaml
new file mode 100644
index 000000000..94450eb77
--- /dev/null
+++ b/manifests/modules/security/secrets-manager/external-secrets/external-secret.yaml
@@ -0,0 +1,13 @@
+apiVersion: external-secrets.io/v1beta1
+kind: ExternalSecret
+metadata:
+  name: "catalog-external-secret"
+  namespace: "catalog"
+spec:
+  refreshInterval: 1h
+  secretStoreRef:
+    name: "cluster-secret-store"
+    kind: ClusterSecretStore
+  dataFrom:
+  - extract:
+      key: "eks-workshop/catalog-secret"
\ No newline at end of file
diff --git a/manifests/modules/security/secrets-manager/external-secrets/kustomization.yaml b/manifests/modules/security/secrets-manager/external-secrets/kustomization.yaml
new file mode 100644
index 000000000..92bed9e55
--- /dev/null
+++ b/manifests/modules/security/secrets-manager/external-secrets/kustomization.yaml
@@ -0,0 +1,8 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+bases:
+- ../../../../base-application/catalog
+patches: 
+- deployment.yaml
+resources:
+- external-secret.yaml
diff --git a/manifests/modules/security/secrets-manager/mounting-secrets/deployment.yaml b/manifests/modules/security/secrets-manager/mounting-secrets/deployment.yaml
new file mode 100644
index 000000000..953b517b1
--- /dev/null
+++ b/manifests/modules/security/secrets-manager/mounting-secrets/deployment.yaml
@@ -0,0 +1,32 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: catalog
+  namespace: catalog
+spec:
+  template:
+    spec:
+      containers:
+        - name: catalog
+          env:
+            - name: DB_USER
+              valueFrom:
+                secretKeyRef:
+                  name: catalog-secret
+                  key: username
+            - name: DB_PASSWORD
+              valueFrom:
+                secretKeyRef:
+                  name: catalog-secret
+                  key: password
+          volumeMounts:
+            - name: catalog-secret
+              mountPath: "/etc/catalog-secret"
+              readOnly: true
+      volumes:
+      - name: catalog-secret
+        csi:
+          driver: secrets-store.csi.k8s.io
+          readOnly: true
+          volumeAttributes:
+            secretProviderClass: catalog-spc
\ No newline at end of file
diff --git a/manifests/modules/security/secrets-manager/mounting-secrets/kustomization.yaml b/manifests/modules/security/secrets-manager/mounting-secrets/kustomization.yaml
new file mode 100644
index 000000000..0d70c2286
--- /dev/null
+++ b/manifests/modules/security/secrets-manager/mounting-secrets/kustomization.yaml
@@ -0,0 +1,6 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+bases:
+- ../../../../base-application/catalog
+patches: 
+- deployment.yaml
diff --git a/manifests/modules/security/secrets-manager/secret-provider-class.yaml b/manifests/modules/security/secrets-manager/secret-provider-class.yaml
new file mode 100644
index 000000000..db511dc37
--- /dev/null
+++ b/manifests/modules/security/secrets-manager/secret-provider-class.yaml
@@ -0,0 +1,24 @@
+apiVersion: secrets-store.csi.x-k8s.io/v1
+kind: SecretProviderClass
+metadata:
+  name: catalog-spc
+  namespace: catalog
+spec:
+  provider: aws
+  parameters:
+    objects: |
+        - objectName: "$EKS_CLUSTER_NAME/catalog-secret"
+          objectType: "secretsmanager"
+          jmesPath:
+            - path: username
+              objectAlias: username
+            - path: password
+              objectAlias: password
+  secretObjects:                
+    - secretName: catalog-secret
+      type: Opaque
+      data:
+        - objectName: username
+          key: username
+        - objectName: password
+          key: password
\ No newline at end of file
diff --git a/website/docs/security/assets/managed-nodegroups.png b/website/docs/security/assets/managed-nodegroups.png
new file mode 100644
index 000000000..5c973dcf9
Binary files /dev/null and b/website/docs/security/assets/managed-nodegroups.png differ
diff --git a/website/docs/security/assets/selfmanaged-nodegroups.png b/website/docs/security/assets/selfmanaged-nodegroups.png
new file mode 100644
index 000000000..81cc02b0f
Binary files /dev/null and b/website/docs/security/assets/selfmanaged-nodegroups.png differ
diff --git a/website/docs/security/index.md b/website/docs/security/index.md
index 229dba020..404fbfbf4 100644
--- a/website/docs/security/index.md
+++ b/website/docs/security/index.md
@@ -9,4 +9,8 @@ Security at AWS is the highest priority, and is a shared responsibility between
 
 In this chapter, we'll explore various aspects of Amazon EKS related to security. To learn more about security with EKS refer to the [EKS Best Practices Guide](https://aws.github.io/aws-eks-best-practices/security/docs/).
 
-![Shared Responsibility](assets/shared-responsibility.jpg)
+![Shared Responsibility](assets/managed-nodegroups.png)
+
+---
+
+![Shared Responsibility](assets/selfmanaged-nodegroups.png)
diff --git a/website/docs/security/sealed-secrets/exploring-secrets.md b/website/docs/security/secrets-management/exploring-secrets.md
similarity index 53%
rename from website/docs/security/sealed-secrets/exploring-secrets.md
rename to website/docs/security/secrets-management/exploring-secrets.md
index 6787e7043..16b7e2c5b 100644
--- a/website/docs/security/sealed-secrets/exploring-secrets.md
+++ b/website/docs/security/secrets-management/exploring-secrets.md
@@ -1,6 +1,6 @@
 ---
 title: "Exploring Secrets"
-sidebar_position: 40
+sidebar_position: 51
 ---
 
 Kubernetes secrets can be exposed to the Pods in different ways such as via environment variables and volumes.
@@ -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% 
-```
diff --git a/website/docs/security/sealed-secrets/index.md b/website/docs/security/secrets-management/index.md
similarity index 53%
rename from website/docs/security/sealed-secrets/index.md
rename to website/docs/security/secrets-management/index.md
index 18e4888f0..fe61263f6 100644
--- a/website/docs/security/sealed-secrets/index.md
+++ b/website/docs/security/secrets-management/index.md
@@ -1,23 +1,11 @@
 ---
-title: "Securing Secrets Using Sealed Secrets"
+title: "Secrets Management"
 sidebar_position: 50
-sidebar_custom_props: {"module": true}
 ---
 
-:::tip Before you start
-Prepare your environment for this section:
-
-```bash timeout=300 wait=30
-$ prepare-environment security/sealed-secrets
-```
-
-:::
-
 [Kubernetes Secret](https://kubernetes.io/docs/concepts/configuration/secret/) is a resource that helps cluster operators manage the deployment of sensitive information such as passwords, OAuth tokens, and ssh keys etc. These secrets can be mounted as data volumes or exposed as environment variables to the containers in a Pod, thus decoupling Pod deployment from managing sensitive data needed by the containerized applications within a Pod.
 
-It has become a common practice for a DevOps Team to manage the YAML manifests for various Kubernetes resources and version control them using a Git repository. This enables them to integrate a Git repository with a GitOps workflow to do Continuous Delivery of such resources to an EKS cluster. 
+It has become a common practice for a DevOps Team to manage the YAML manifests for various Kubernetes resources and version control them using a Git repository. This enables them to integrate a Git repository with a GitOps workflow to do Continuous Delivery of such resources to an EKS cluster.
 Kubernetes obfuscate sensitive data in a Secret by using a merely base64 encoding, also storing such files in a Git repository is extremely insecure as it is trivial to decode the base64 encoded data. This makes it difficult to manage the YAML manifests for Kubernetes Secrets outside a cluster.
 
-[Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets) provides a mechanism to encrypt a Secret object so that it is safe to store - even to a public repository. A SealedSecret can be decrypted only by the controller running in the Kubernetes cluster and nobody else is able to obtain the original Secret from a SealedSecret.
-
-In this chapter, you will use SealedSecrets to encrypt YAML manifests pertaining to Kubernetes Secrets as well as be able to deploy these encrypted Secrets to your EKS clusters using normal workflows with tools such as [kubectl](https://kubernetes.io/docs/reference/kubectl/).
+There are a few different approaches you can use for secrets management, in this chapter for Secrets Management, we will cover a couple of them, [Sealed Secrets for Kubernetes](https://github.com/bitnami-labs/sealed-secrets) and [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
diff --git a/website/docs/security/secrets-management/sealed-secrets/index.md b/website/docs/security/secrets-management/sealed-secrets/index.md
new file mode 100644
index 000000000..8f1ef220c
--- /dev/null
+++ b/website/docs/security/secrets-management/sealed-secrets/index.md
@@ -0,0 +1,22 @@
+---
+title: "Securing Secrets Using Sealed Secrets"
+sidebar_position: 70
+sidebar_custom_props: {"module": true}
+---
+
+:::caution
+The [Sealed Secrets](https://docs.bitnami.com/tutorials/sealed-secrets) project is not related to AWS Services but a third party open-source tool from [Btinami Labs](https://bitnami.com/)
+:::
+
+
+:::tip Before you start
+Prepare your environment for this section:
+
+```bash timeout=300 wait=30
+$ prepare-environment security/sealed-secrets
+```
+:::
+
+[Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets) provides a mechanism to encrypt a Secret object so that it is safe to store - even to a public repository. A SealedSecret can be decrypted only by the controller running in the Kubernetes cluster and nobody else is able to obtain the original Secret from a SealedSecret.
+
+In this chapter, you will use SealedSecrets to encrypt YAML manifests pertaining to Kubernetes Secrets as well as be able to deploy these encrypted Secrets to your EKS clusters using normal workflows with tools such as [kubectl](https://kubernetes.io/docs/reference/kubectl/).
diff --git a/website/docs/security/sealed-secrets/installing-sealed-secrets.md b/website/docs/security/secrets-management/sealed-secrets/installing-sealed-secrets.md
similarity index 99%
rename from website/docs/security/sealed-secrets/installing-sealed-secrets.md
rename to website/docs/security/secrets-management/sealed-secrets/installing-sealed-secrets.md
index 0276313ac..765e8c4ee 100644
--- a/website/docs/security/sealed-secrets/installing-sealed-secrets.md
+++ b/website/docs/security/secrets-management/sealed-secrets/installing-sealed-secrets.md
@@ -1,6 +1,6 @@
 ---
 title: "Installing Sealed Secrets"
-sidebar_position: 60
+sidebar_position: 72
 ---
 
 The `kubeseal` CLI is used to interact with the sealed secrets controller, and has already been installed in Cloud9.
diff --git a/website/docs/security/sealed-secrets/managing-sealing-keys.md b/website/docs/security/secrets-management/sealed-secrets/managing-sealing-keys.md
similarity index 99%
rename from website/docs/security/sealed-secrets/managing-sealing-keys.md
rename to website/docs/security/secrets-management/sealed-secrets/managing-sealing-keys.md
index f0f43ef87..2ad757413 100644
--- a/website/docs/security/sealed-secrets/managing-sealing-keys.md
+++ b/website/docs/security/secrets-management/sealed-secrets/managing-sealing-keys.md
@@ -1,6 +1,6 @@
 ---
 title: "Managing the Sealing Key"
-sidebar_position: 80
+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.
diff --git a/website/docs/security/sealed-secrets/sealing-secrets.md b/website/docs/security/secrets-management/sealed-secrets/sealing-secrets.md
similarity index 66%
rename from website/docs/security/sealed-secrets/sealing-secrets.md
rename to website/docs/security/secrets-management/sealed-secrets/sealing-secrets.md
index 3808b2ad7..6139c7a22 100644
--- a/website/docs/security/sealed-secrets/sealing-secrets.md
+++ b/website/docs/security/secrets-management/sealed-secrets/sealing-secrets.md
@@ -1,8 +1,58 @@
 ---
 title: "Sealing your Secrets"
-sidebar_position: 70
+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
diff --git a/website/docs/security/sealed-secrets/working.md b/website/docs/security/secrets-management/sealed-secrets/working.md
similarity index 99%
rename from website/docs/security/sealed-secrets/working.md
rename to website/docs/security/secrets-management/sealed-secrets/working.md
index 64d03619d..4259221f2 100644
--- a/website/docs/security/sealed-secrets/working.md
+++ b/website/docs/security/secrets-management/sealed-secrets/working.md
@@ -1,6 +1,6 @@
 ---
 title: "Sealed Secrets for Kubernetes"
-sidebar_position: 50
+sidebar_position: 71
 ---
 
 Sealed Secrets is composed of two parts:
diff --git a/website/docs/security/secrets-management/secrets-manager/ascp.md b/website/docs/security/secrets-management/secrets-manager/ascp.md
new file mode 100644
index 000000000..4e81fe4d5
--- /dev/null
+++ b/website/docs/security/secrets-management/secrets-manager/ascp.md
@@ -0,0 +1,75 @@
+---
+title: "AWS Secrets and Configuration Provider (ASCP)"
+sidebar_position: 62
+---
+
+When 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.
+
+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
+```
+
+In order to provide access to your secrets stored in AWS Secrets Manager via CSI driver, you'll need a *SecretProviderClass*, which is a namespaced custom resource that's used provide driver configurations and specific parameters that match the information in AWS Secrets Manager. 
+
+```file
+manifests/modules/security/secrets-manager/secret-provider-class.yaml
+```
+
+In the above resource, you have two main configurations that you should be focusing. So go head and create the resource to explore those specifications.
+
+```bash
+$ cat eks-workshop/modules/security/secrets-manager/secret-provider-class.yaml | envsubst | kubectl apply -f -
+```
+
+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.
+
+
+```bash
+$ kubectl get secretproviderclass -n catalog catalog-spc -o yaml | yq '.spec.parameters.objects'
+
+- objectName: "eks-workshop/catalog-secret"
+  objectType: "secretsmanager"
+  jmesPath:
+    - path: username
+      objectAlias: username
+    - path: password
+      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 is named `catalog-secret`.
+
+```bash
+$ kubectl get secretproviderclass -n catalog catalog-spc -o yaml | yq '.spec.secretObjects'
+
+- data:
+    - key: username
+      objectName: username
+    - key: password
+      objectName: password
+  secretName: catalog-secret
+  type: Opaque
+```
diff --git a/website/docs/security/secrets-management/secrets-manager/assets/choose-type.png b/website/docs/security/secrets-management/secrets-manager/assets/choose-type.png
new file mode 100644
index 000000000..bb6820cb8
Binary files /dev/null and b/website/docs/security/secrets-management/secrets-manager/assets/choose-type.png differ
diff --git a/website/docs/security/secrets-management/secrets-manager/assets/configure-secret.png b/website/docs/security/secrets-management/secrets-manager/assets/configure-secret.png
new file mode 100644
index 000000000..ce09ab6cb
Binary files /dev/null and b/website/docs/security/secrets-management/secrets-manager/assets/configure-secret.png differ
diff --git a/website/docs/security/secrets-management/secrets-manager/assets/store-new-secret.png b/website/docs/security/secrets-management/secrets-manager/assets/store-new-secret.png
new file mode 100644
index 000000000..df42aca13
Binary files /dev/null and b/website/docs/security/secrets-management/secrets-manager/assets/store-new-secret.png differ
diff --git a/website/docs/security/secrets-management/secrets-manager/create-secret.md b/website/docs/security/secrets-management/secrets-manager/create-secret.md
new file mode 100644
index 000000000..0bfb12e9f
--- /dev/null
+++ b/website/docs/security/secrets-management/secrets-manager/create-secret.md
@@ -0,0 +1,34 @@
+---
+title: "Storing secrets in AWS Secrets Manager"
+sidebar_position: 61
+---
+
+First, we need to store a secret in AWS Secrets Manager, lets do that using the AWS CLI, by running the command like the example below in you Cloud9 Environment.
+
+```bash
+$ aws secretsmanager create-secret --name "$EKS_CLUSTER_NAME/catalog-secret" --secret-string '{"username":"catalog_user", "password":"default_password"}' --region $AWS_REGION
+{
+    "ARN": "arn:aws:secretsmanager:$AWS_REGION:$AWS_ACCOUNT_ID:secret:$EKS_CLUSTER_NAME/catalog-secret-ABCdef",
+    "Name": "eks-workshop/static-secret",
+    "VersionId": "7e0b352d-6666-4444-aaaa-cec1f1d2df1b"
+}
+```
+
+The command above is storing a secret with a JSON encoded key/value content, for `username` and `password` credentials.
+
+Validate the new stored secret in the [AWS Secrets Manager Console](https://console.aws.amazon.com/secretsmanager/listsecrets) or run the below command in your Cloud9 Environment.
+
+```bash
+$ aws secretsmanager describe-secret --secret-id "$EKS_CLUSTER_NAME/catalog-secret"
+{
+    "ARN": "arn:aws:secretsmanager:us-west-2:068535243777:secret:eks-workshop/catalog-secret-WDD8yS",
+    "Name": "eks-workshop/catalog-secret",
+    "LastChangedDate": "2023-10-10T20:44:51.882000+00:00",
+    "VersionIdsToStages": {
+        "94d1fe43-87f5-42fb-bf28-f6b090f0ca44": [
+            "AWSCURRENT"
+        ]
+    },
+    "CreatedDate": "2023-10-10T20:44:51.439000+00:00"
+}
+```
diff --git a/website/docs/security/secrets-management/secrets-manager/external-secrets.md b/website/docs/security/secrets-management/secrets-manager/external-secrets.md
new file mode 100644
index 000000000..9b0bb4298
--- /dev/null
+++ b/website/docs/security/secrets-management/secrets-manager/external-secrets.md
@@ -0,0 +1,148 @@
+---
+title: "External Secrets Operator"
+sidebar_position: 64
+---
+
+The `prepare-environment` script that you ran in a [previous step](./index.md), has already deployed the External Secrets Operator addon required for this lab.
+
+Let's validate the created addon.
+
+```bash
+$ kubectl -n external-secrets get pods
+NAME                                                READY   STATUS    RESTARTS   AGE
+external-secrets-6d95d66dc8-5trlv                   1/1     Running   0          7m
+external-secrets-cert-controller-774dff987b-krnp7   1/1     Running   0          7m
+external-secrets-webhook-6565844f8f-jxst8           1/1     Running   0          7m
+$ kubectl -n external-secrets get sa 
+NAME                  SECRETS   AGE
+default               0         7m
+external-secrets-sa   0         7m
+```
+
+As you can see, you have a ServiceAccount named `external-secrets-sa`, this SA is tied to an [IRSA](../../iam-roles-for-service-accounts/), with access to AWS Secrets Manager, for retrieving secrets information.
+
+```bash
+$ kubectl -n external-secrets describe sa external-secrets-sa | grep Annotations
+Annotations:         eks.amazonaws.com/role-arn: arn:aws:iam::068535243777:role/eks-workshop-external-secrets-sa-irsa
+```
+
+In addition to that, you'll need to create a new cluster resource called `ClusterSecretStore` which is a cluster wide SecretStore that can be referenced by all ExternalSecrets from all namespaces.
+
+```file
+manifests/modules/security/secrets-manager/cluster-secret-store.yaml
+```
+
+```bash
+$ cat eks-workshop/modules/security/secrets-manager/cluster-secret-store.yaml | envsubst | kubectl apply -f -
+```
+
+Take a deeper look in this newly created resource specifications.
+
+```bash
+$ kubectl get clustersecretstores.external-secrets.io 
+NAME                   AGE   STATUS   CAPABILITIES   READY
+cluster-secret-store   81s   Valid    ReadWrite      True
+$ kubectl get clustersecretstores.external-secrets.io cluster-secret-store  -o yaml | yq '.spec'
+provider:
+  aws:
+    auth:
+      jwt:
+        serviceAccountRef:
+          name: external-secrets-sa
+          namespace: external-secrets
+    region: us-west-2
+    service: SecretsManager
+
+```
+
+You can see here, that it's using a [JSON Web Token (jwt)](https://jwt.io/), referenced to the ServiceAccount we just checked, to sync with AWS Secrets Manager.
+
+Let's move forward and create an `ExternalSecret`, that describes what data should be fetched from AWS Secrets Manager, how the data should be transformed and saved as a Kubernetes Secret. And also patch our `catalog` Deployment to use the External Secret as source for the credentials.
+
+```kustomization
+modules/security/secrets-manager/external-secrets/kustomization.yaml
+Deployment/catalog
+ExternalSecret/catalog-external-secret
+```
+
+```bash
+$ kubectl apply -k eks-workshop/modules/security/secrets-manager/external-secrets/
+```
+
+Check the newly created `ExternalSecret` resouce.
+
+```bash
+$ kubectl -n catalog get externalsecrets.external-secrets.io                                                                                                                                                                                                                            
+NAME                      STORE                  REFRESH INTERVAL   STATUS         READY
+catalog-external-secret   cluster-secret-store   1h                 SecretSynced   True
+```
+
+Verify that the resource has a `SecretSynced` status, which means that it was successfully syncronized from AWS Secrets Manager. Let's take a closer look to this resource specifications.
+
+```bash
+$ kubectl -n catalog get externalsecrets.external-secrets.io catalog-external-secret -o yaml | yq '.spec'
+dataFrom:
+  - extract:
+      conversionStrategy: Default
+      decodingStrategy: None
+      key: eks-workshop/catalog-secret
+refreshInterval: 1h
+secretStoreRef:
+  kind: ClusterSecretStore
+  name: cluster-secret-store
+target:
+  creationPolicy: Owner
+  deletionPolicy: Retain
+```
+
+Notice the `key` and the `secretStoreRef` parameter, pointing to the secret we stored on AWS Secrets Manager, and the `ClusterSecretStore` previously created. Also the `refreshInterval` is set to 1 hours, which means that the value from this secret will be checked and refreshed every hour.
+
+But how do we use this ExternalSecret in our Pods? After we create this resouces, it automatically created a Kubernetes secret with the same name in the Namespace.
+
+```bash
+$ kubectl -n catalog get secrets
+NAME                      TYPE     DATA   AGE
+catalog-db                Opaque   2      21h
+catalog-external-secret   Opaque   2      1m
+catalog-secret            Opaque   2      5h40m
+```
+
+Take a deeper look in this secret.
+
+```bash
+$ kubectl -n catalog get secret catalog-external-secret -o yaml | yq '.metadata.ownerReferences'
+- apiVersion: external-secrets.io/v1beta1
+  blockOwnerDeletion: true
+  controller: true
+  kind: ExternalSecret
+  name: catalog-external-secret
+  uid: b8710001-366c-44c2-8e8d-462d85b1b8d7
+```
+
+See that it has an `ownerReference` that points to External Secrets Operator.
+
+Now check that the `catalog` Pod, is already updated with the values from this new secret, and it's up and running!
+
+```bash
+$ kubectl -n catalog get pods
+NAME                       READY   STATUS    RESTARTS   AGE
+catalog-777c4d5dc8-lmf6v   1/1     Running   0          1m
+catalog-mysql-0            1/1     Running   0          24h
+$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .env'
+- name: DB_USER
+  valueFrom:
+    secretKeyRef:
+      key: username
+      name: catalog-external-secret
+- name: DB_PASSWORD
+  valueFrom:
+    secretKeyRef:
+      key: password
+      name: catalog-external-secret
+```
+
+### Conclusion
+
+In conclusion, there is no best option on choosing between **AWS Secrets and Configuration Provider (ASCP)** vs. **External Secrets Operator (ESO)** in order to manage your secrets stored 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.
diff --git a/website/docs/security/secrets-management/secrets-manager/index.md b/website/docs/security/secrets-management/secrets-manager/index.md
new file mode 100644
index 000000000..b005b5595
--- /dev/null
+++ b/website/docs/security/secrets-management/secrets-manager/index.md
@@ -0,0 +1,34 @@
+---
+title: "Managing Secrets with AWS Secrets Manager"
+sidebar_position: 60
+sidebar_custom_props: {"module": true}
+---
+
+:::tip Before you start
+Prepare your environment for this section:
+
+```bash timeout=300 wait=30
+$ prepare-environment security/secrets-manager
+```
+
+This will make the following changes to your lab environment:
+
+Install the following Kuberentes Addons in your EKS Cluter:
+* Kubernetes Secrets Store CSI Driver
+* AWS Secrets and Configuration Provider
+* External Secrets Operator
+
+You can view the Terraform that applies these changes [here](https://github.com/aws-samples/eks-workshop-v2/tree/main/manifests/modules/security/secrets/secrets-manager/.workshop/terraform).
+
+:::
+
+[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.
+
+Another way to integrate AWS Secrets Manager with Kubernetes Secrets, is through [External Secrets](https://external-secrets.io/). External Secrets is an operator that can integrate and synchronize secrets from AWS Secrets Manager reading the information from it and automatically injecting the values into a Kubernetes Secret with an abstraction that stores and manages the lifecycle of the secrets for you.
+
+If you use Secrets Manager automatic rotation for your secrets, you can rely on External Secrets refresh interaval or use the Secrets Store CSI Driver rotation reconciler feature to ensure you are retrieving the latest secret from Secrets Manager, depending on the tool you choose to manage secrets inside your Amazon EKS Cluster.
+
+In this lab following section, we will create a couple of example scenarios of using secrets from AWS Secrets Manager and External Secrets.
diff --git a/website/docs/security/secrets-management/secrets-manager/mounting-secrets.md b/website/docs/security/secrets-management/secrets-manager/mounting-secrets.md
new file mode 100644
index 000000000..0d3c65db0
--- /dev/null
+++ b/website/docs/security/secrets-management/secrets-manager/mounting-secrets.md
@@ -0,0 +1,120 @@
+---
+title: "Mounting AWS Secrets Manager secret on Kubernetes Pod"
+sidebar_position: 63
+---
+
+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:
+
+* `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
+```
+
+Notice that the `catalog` Deployment don't have any `volumes` or `volumeMounts` other than an `emptyDir` mounted on `/tmp`
+
+```bash
+$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.volumes'
+- emptyDir:
+    medium: Memory
+  name: tmp-volume
+$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .volumeMounts'
+- mountPath: /tmp
+  name: tmp-volume
+```
+
+Let's go and apply the changes in the `catalog` Deployment to use the secret stored in AWS Secrets Manager as the source of the credentials.
+
+```kustomization
+modules/security/secrets-manager/mounting-secrets/kustomization.yaml
+Deployment/catalog
+```
+
+Here you will be mounting the AWS Secrets Manager secret using the CSI driver with the SecretProviderClass you validated earlier on the `/etc/catalog-secret` mountPath inside the Pod. When this happens, AWS Secrets Manager will sync the content of the stored secret with Amazon EKS, and create a Kubernetes Secret with the same contents that can be consumed as Environment variables in the Pod.
+
+```bash
+$ kubectl apply -k ~/environment/eks-workshop/modules/security/secrets-manager/mounting-secrets/
+```
+
+Let's validate the changes made in the `catalog` Namespace.
+
+In the Deployment, youll' be able to check that it has a new `volume` and respective `volumeMount` pointing to the CSI Secret Store Driver, and mounted on `/etc/catalog-secrets` path.
+
+```bash
+$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.volumes'
+- csi:
+    driver: secrets-store.csi.k8s.io
+    readOnly: true
+    volumeAttributes:
+      secretProviderClass: catalog-spc
+  name: catalog-secret
+- emptyDir:
+    medium: Memory
+  name: tmp-volume
+$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .volumeMounts'                                                                                                                                                                             
+- mountPath: /etc/catalog-secret
+  name: catalog-secret
+  readOnly: true
+- mountPath: /tmp
+  name: tmp-volume
+```
+
+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'
+- name: DB_USER
+  valueFrom:
+    secretKeyRef:
+      key: username
+      name: catalog-secret
+- name: DB_PASSWORD
+  valueFrom:
+    secretKeyRef:
+      key: password
+      name: catalog-secret
+$ kubectl -n catalog get secrets
+NAME             TYPE     DATA   AGE
+catalog-db       Opaque   2      15h
+catalog-secret   Opaque   2      43s
+```
+
+Now you have a Kubernetes Secrets fully integrated with AWS Secrets Manager, that can leverage secrets rotation which is a best practice for Secrets Management. So everytime a secret is rotated or updated on AWS Secrets Manager, you'll just need to rollout a new version of your Deployment for the CSI Secret Store driver can sync the Kubernetes Secrets contents.