Move to different repo? Add Support for Native Secrets Management services

[rubentalstra]

Summary

Closes: #4545

This change adds native support for deploying secrets to AWS, Azure, and Google Cloud’s secrets management services. The script now handles secret creation and updating for:

• AWS Secrets Manager: Creates or updates each environment variable as a secret.
• Azure Key Vault & Web App: Depending on the target specified, it either sets secrets in Key Vault or updates the Web App’s application settings.
• GCP Secret Manager: Creates a secret or adds a new version if the secret already exists.

Change Type

• New feature (non-breaking change which adds functionality)

Testing

Test Configuration:

1. AWS Testing:

   • Set AWS_REGION and your AWS credentials (e.g., AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY).
   • Run the script:

     node deploy-secrets.js --provider aws

   • Verify that each non-excluded variable is created or updated in AWS Secrets Manager.

2. Azure Testing:

   • For Key Vault deployment:
     • Set KEY_VAULT_URL along with necessary Azure credentials.
     • Run the script:

       node deploy-secrets.js --provider azure --target keyvault

     • Verify that the secrets are set in the specified Azure Key Vault.
   • For Web App deployment:
     • Set AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, and AZURE_WEBAPP_NAME along with other required credentials.
     • Run the script:

       node deploy-secrets.js --provider azure --target webapp

     • Verify that the Web App’s application settings are updated with the new environment variables.

3. GCP Testing:

   • Set GCP_PROJECT_ID and configure your GCP credentials.
   • Run the script:

     node deploy-secrets.js --provider gcp

   • Verify that each non-excluded variable is created (or a new version is added) in GCP Secret Manager.

• Only the active (non-commented) environment variables from the .env file are processed.
• The deployment logic correctly distinguishes between creating new secrets and updating existing ones across providers.

Checklist

• My code adheres to this project's style guidelines
• I have performed a self-review of my own code
• I have commented in any complex areas of my code
• I have made pertinent documentation changes
• My changes do not introduce new warnings
• I have written tests demonstrating that my changes are effective or that my feature works
• Local unit tests pass with my changes
• Any changes dependent on mine have been merged and published in downstream modules.
• A pull request for updating the documentation has been submitted.

[danny-avila]

I would prefer if packages could not be installed that may never be used. Maybe this makes more sense as a separate repo companion to a deployment on these services?

[rubentalstra]

I think that would be a good idea. would you create a Repo? where these extra deployment features could be shared?