Update manage-encrypted-secrets.md

Author: Chukslord1

learn-pr/github/manage-github-actions-enterprise/includes/manage-encrypted-secrets.md

@@ -2,6 +2,28 @@ Secrets are encrypted environment variables you can create to store tokens, cred
 
 In this section, you'll explore the different tools and strategies available in GitHub Enterprise Cloud and GitHub Enterprise Server in order to manage the use of encrypted secrets. We'll also explain how to access encrypted secrets in your workflows and actions.
 
+## 6.3 Manage Encrypted Secrets in the Enterprise
+
+GitHub Actions provides a way to securely store and use sensitive information like API keys, authentication tokens, passwords, and certificates using **encrypted secrets**. These secrets are securely stored and injected into workflows, ensuring they are never exposed in logs or code repositories.
+
+In an enterprise environment, managing secrets effectively is crucial for security, compliance, and operational efficiency. Secrets in GitHub are managed at different scopes, including **enterprise, organization, repository, and environment levels**.
+
+### 6.3.1 Identify the Scope of Encrypted Secrets
+
+Understanding the **scope** of secrets is key to managing them securely in an enterprise environment.
+
+| **Secret Level**               | **Scope**                                                                                              | **Who Can Access?**                                    | **Use Cases**                                                                    |
+| ------------------------------ | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------ | -------------------------------------------------------------------------------- |
+| **Enterprise-Level Secrets**   | Available across all repositories within a GitHub Enterprise Cloud organization.                       | Enterprise owners, security administrators             | Standard API keys, shared service credentials used across multiple repositories. |
+| **Organization-Level Secrets** | Available to all repositories within a specific organization. Can be limited to selected repositories. | Organization owners, security administrators           | Shared tokens for accessing cloud services, database credentials.                |
+| **Repository-Level Secrets**   | Limited to a single repository.                                                                        | Repository admins and workflow runners.                | Repository-specific database credentials, API keys for deployment.               |
+| **Environment-Level Secrets**  | Scoped to a specific deployment environment within a repository (e.g., `staging`, `production`).       | Workflow runners executing in the defined environment. | Secrets required for deployments in different environments.                      |
+
+**Key Considerations:**
+- **Enterprise Secrets** are only available in GitHub Enterprise Cloud, providing a centralized way to manage organization-wide secrets.
+- **Organization Secrets** can be scoped to selected repositories to enforce the **principle of least privilege**.
+- **Environment Secrets** help prevent accidental exposure of production credentials by limiting access based on workflow environments.
+
 ## Manage encrypted secrets at organization level
 
 Creating encrypted secrets at organization level to store sensitive information is a great way to ensure the security of this information, while minimizing management overhead in your enterprise.
@@ -18,6 +40,32 @@ The access policy appears underneath the secret in the secret list once it's sav
 
 You can select **Update** for more details on the configured permissions for your secret.
 
+### 6.3.3 Manage Organization-Level Encrypted Secrets
+
+#### Managing Organization Secrets via GitHub CLI
+
+- **Create a secret for an organization:**
+  ```sh
+  gh secret set SECRET_NAME --org my-org --body "super-secret-value"
+  ```
+- **List all organization secrets:**
+  ```sh
+  gh secret list --org my-org
+  ```
+- **Update an existing secret:**
+  ```sh
+  gh secret set SECRET_NAME --org my-org --body "new-secret-value"
+  ```
+- **Delete a secret:**
+  ```sh
+  gh secret delete SECRET_NAME --org my-org
+  ```
+
+#### Security Considerations for Organization Secrets
+- **Restrict secrets to specific repositories** instead of allowing all repositories to use them.
+- **Use role-based access control (RBAC)** to ensure only necessary personnel can update secrets.
+- **Monitor access logs** to detect unauthorized usage.
+
 ## Manage encrypted secrets at repository level
 
 If you need an encrypted secret to be scoped to a specific repository, GitHub Enterprise Cloud and GitHub Enterprise Server also let you create secrets at repository level.
@@ -26,6 +74,22 @@ To create a secret at repository level, go to your repository **Settings** and f
 
 :::image type="content" source="../media/secret-repo.png" alt-text="New secret screen for repositories.":::
 
+### 6.3.4 Manage Repository-Level Encrypted Secrets
+
+#### Managing Repository Secrets via CLI
+- **List repository secrets:**
+  ```sh
+  gh secret list --repo my-repo
+  ```
+- **Update a repository secret:**
+  ```sh
+  gh secret set SECRET_NAME --repo my-repo --body "new-secret-value"
+  ```
+- **Delete a repository secret:**
+  ```sh
+  gh secret delete SECRET_NAME --repo my-repo
+  ```
+
 ## Access encrypted secrets within actions and workflows
 
 ### In workflows
@@ -56,3 +120,71 @@ If you need to access the encrypted secret in your action's code, the action cod
 
 > [!WARNING]
 > When authoring your own actions, make sure not to include any encrypted secrets in your action's source code, because actions are sharable units of work. If your action needs to use encrypted secrets or other user-supplied inputs, it's best to use the core module from the [Actions Toolkit](https://github.com/actions/toolkit).
+
+### 6.3.2 Access Encrypted Secrets Within Actions and Workflows
+
+#### Example: Using a Secret in a Workflow
+
+```yaml
+name: Deploy Application
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v3
+
+      - name: Use secret in a script
+        run: echo "Deploying with API_KEY=${{ secrets.DEPLOYMENT_KEY }}"
+```
+
+#### Best Practices for Using Secrets in Workflows
+- **Do not print secrets** in logs using `echo ${{ secrets.SECRET_NAME }}`.
+- **Use secrets within script commands**, rather than assigning them to environment variables.
+- **Limit access** by defining secrets at the **lowest necessary level**.
+- **Rotate secrets periodically** and update workflows accordingly.
+
+## 6.3.5 Describe How to Use 3rd Party Vaults
+
+Many enterprises integrate GitHub Actions with external secret management solutions like **HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault**.
+
+### 1. HashiCorp Vault
+```yaml
+- name: Fetch secret from Vault
+  id: vault
+  uses: hashicorp/vault-action@v2
+  with:
+    url: https://vault.example.com
+    token: ${{ secrets.VAULT_TOKEN }}
+    secret: secret/data/github/my-secret
+```
+
+### 2. AWS Secrets Manager
+```yaml
+- name: Retrieve AWS Secret
+  run: |
+    SECRET_VALUE=$(aws secretsmanager get-secret-value --secret-id my-secret | jq -r .SecretString)
+    echo "SECRET_VALUE=${SECRET_VALUE}" >> $GITHUB_ENV
+```
+
+### 3. Azure Key Vault
+```yaml
+- name: Retrieve Azure Secret
+  uses: Azure/get-keyvault-secrets@v1
+  with:
+    keyvault: "my-keyvault"
+    secrets: "my-secret"
+    azureCredentials: ${{ secrets.AZURE_CREDENTIALS }}
+```
+
+### Benefits of Using Third-Party Vaults
+- **Centralized secret management** reduces security risks.  
+- **Automated secret rotation** helps comply with security policies.  
+- **Audit logs and access control** enhance security monitoring.  
+- **Least privilege access** prevents unauthorized use of secrets.