Adding outline for section 3 of the cheatsheet, updating #124

cheatsheets_draft/Secrets_Management_CheatSheet.md

@@ -133,16 +133,41 @@ A secret management solution should provide the capability to store at least the
 - What tyep of secret it is (E.g. AES Key, HMAC key, RSA private key)
 - When it needs to be rotated, if done manually
 
-## 3. Continuous Integration (CI) and Continuous Deployment (CD)
-The process of integrating features and deploying changes commonly requires secrets to several systems, such as version control.
+## 3 Continuous Integration (CI) and Continuous Deployment (CD)
 
-### 3.1. Build Tools    
+The process of integrating features and deploying changes commonly requires secrets to several systems, such as version control, the infrastructure provider on which the new assets need to be deployed, and possibly other items, such as artifactories and such. There are various best-practices which can help smoothing out secret management in CI/CD, some of them will be dealt with in this section.
 
-### 3.2. Rotation vs Dynamic Creation
+### 3.1 Where is the secret?
 
-### 3.3. Identity Authentication
+- DO YOU PUT THE SECRET IN GIT PROVISIONGIN SYSTEM?J
+- DO YOU PUT THE SECRET IN YOUR BUILDTOOL?
+- DO THESE SYSTEMS HAVE A LINK TO A SECRETS MANAGEMENT SYSTEM WHICH HAS THE SECRET?
 
-### 3.4. Deployment
+#### 3.1.1 Using Git provisioning system
+
+EXPLAIN DO'S AND DON'TS
+
+#### 3.1.2 Using the pipeline tool
+
+EXPLAIN DO'S AND DON'TS
+
+#### 3.1.3 Storing it in a secrets management system
+
+EXPLAIN DO'S AND DON'TS
+
+### 3.3: Authentication and Authorization
+
+HOW DOES A PIPELIEN AUTHENTICATE? HOW DO YOU KNOW AUTHORIZAITON IS OK?
+
+### 3.3: Logging and accounting
+
+HOW CAN YOU TELL WHO ACCESSED THE SECRET WITH THE PIPELINE?
+
+### 3.4. Rotation vs Dynamic Creation
+
+### 3.5. Bring the Secret close to the consumer
+
+EXPLAIN WHAT YOU CAN DO INSTEAD: LEVERAGE POST-DEPLOYMENT TO LET THE ACTUAL APP DO
 
 ## 4. Cloud Providers
 
@@ -157,13 +182,17 @@ The process of integrating features and deploying changes commonly requires secr
 ## 5. Containers & Orchestrators
 
 ### 5.1. Injection of Secrets (file, in-memory)
-    Ther are 3 ways to get secrets to an app inside a docker container
-    * Environment variables: We can provide secrets directly as the part of the docker container configuration. In this method the secrets could be either hard coded in docker configuration file or could be passed as argument at docker runtime.
-    * Mounted volumes (file): In this method we keep our secrets within a particular config/secret file and mount that file to our instance as a mounted volume.
-    * Fetch from secret store (in-memory): A sidecar app/container fetches the secrets it need directly from a secret manager service without having to deal with docker config. This solution allows you to use dynamically constructed secrets without worrying about the secrets being viewable from the file system or from checking the docker container's env variables.
+
+Ther are 3 ways to get secrets to an app inside a docker container
+
+- Environment variables: We can provide secrets directly as the part of the docker container configuration. In this method the secrets could be either hard coded in docker configuration file or could be passed as argument at docker runtime.
+- Mounted volumes (file): In this method we keep our secrets within a particular config/secret file and mount that file to our instance as a mounted volume.
+- Fetch from secret store (in-memory): A sidecar app/container fetches the secrets it need directly from a secret manager service without having to deal with docker config. This solution allows you to use dynamically constructed secrets without worrying about the secrets being viewable from the file system or from checking the docker container's env variables.
+
 ### 5.2. Short Lived Side-car Containers
-    To inject secret within a container one could create short lived side-car containers that fethces secret from some remote end point and then store them on a
-    shared volume which is also mounted to the original container. The original container can now use the secrets from mounted volume benefit of using this approach is that we don't need to integrate any third party tool or code to get secrets. Once the secret are fethced the side car container dies and that's why they are called short lived. Example of one such service is Vault Agent Sidecar Injector. The Vault Agent Injector alters pod specifications to include Vault Agent containers that render Vault secrets to a shared memory volume using Vault Agent Templates. By rendering secrets to a shared volume, containers within the pod can consume Vault secrets without being Vault aware 
+
+To inject secret within a container one could create short lived side-car containers that fethces secret from some remote end point and then store them on a shared volume which is also mounted to the original container. The original container can now use the secrets from mounted volume benefit of using this approach is that we don't need to integrate any third party tool or code to get secrets. Once the secret are fethced the side car container dies and that's why they are called short lived. Example of one such service is Vault Agent Sidecar Injector. The Vault Agent Injector alters pod specifications to include Vault Agent containers that render Vault secrets to a shared memory volume using Vault Agent Templates. By rendering secrets to a shared volume, containers within the pod can consume Vault secrets without being Vault aware.
+
 ### 5.3. Internal vs External Access
 
 ## 6. Implementation Guidance