如何在AWS CodeBuild中加载未纳入源码控制的环境变量文件
Absolutely! Storing your sensitive env.ts file in S3 and retrieving it during the CodeBuild phase is a straightforward, secure way to fix your build failures. Here's how to implement this end-to-end:
Step 1: Upload env.ts to an S3 Bucket
First, create an S3 bucket (or use an existing one) to store your env.ts file. Make sure to:
- Restrict public access: Disable all public access settings for the bucket to keep your sensitive data secure.
- Enable server-side encryption: Use S3-managed keys (SSE-S3) or AWS KMS to encrypt the file at rest.
- Upload the file: Use the AWS CLI, S3 console, or SDK to upload your local
env.tsto the bucket. For example:aws s3 cp ./env.ts s3://your-secrets-bucket/path/to/env.ts
Step 2: Grant CodeBuild Access to the S3 File
Your CodeBuild project uses an IAM service role—you need to add permissions for this role to read the env.ts file from S3.
- Go to the IAM console, find your CodeBuild service role (usually named something like
codebuild-<project-name>-service-role). - Attach a new inline policy with the following permissions (replace
your-secrets-bucketand the file path with your actual values):{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::your-secrets-bucket/path/to/env.ts" } ] }
Step 3: Update Your buildspec.yml to Pull the File
Modify your buildspec to fetch env.ts during the install phase, before running yarn install or any commands that depend on the file. You'll need to copy it to the correct location where your code expects it (based on the @env alias—usually the root of your project directory, $CODEBUILD_SRC_DIR).
Here's the updated buildspec:
version: 0.2 phases: install: commands: - echo installing packages... - npm install --global yarn # Pull env.ts from S3 to the project root - aws s3 cp s3://your-secrets-bucket/path/to/env.ts $CODEBUILD_SRC_DIR/env.ts - yarn install build: commands: # Make sure NODE_ENV is set (you can also define this in CodeBuild project settings) - export NODE_ENV=test # or prod, depending on your build target - echo running tests... - yarn jest - echo building... - yarn build artifacts: files: - $CODEBUILD_SRC_DIR/dist/prod/*
Key Notes & Security Best Practices
- Set NODE_ENV: Your code relies on
process.env.NODE_ENVto pick the right config—you can either define this in the buildspec (as shown) or set it as an environment variable directly in your CodeBuild project settings (more flexible for different build stages). - Avoid hardcoding paths: If you need to reuse this across projects, consider storing the S3 path as a CodeBuild environment variable (e.g.,
S3_ENV_FILE_PATH) and reference it in the buildspec likeaws s3 cp $S3_ENV_FILE_PATH $CODEBUILD_SRC_DIR/env.ts. - Rotate credentials: If your
env.tscontains sensitive API keys or passwords, regularly update the file in S3 and ensure old versions are deleted (enable S3 versioning to recover if needed, but clean up stale versions). - Consider alternative tools: For more dynamic secret management, you could use AWS Secrets Manager or Parameter Store to inject values into a template
env.tsduring build time—but pulling the file directly from S3 is a great starting point for your use case.
Once you've made these changes, trigger a new CodePipeline build—your env.ts will be available during the build process, and your tests and build steps should run successfully.
内容的提问来源于stack exchange,提问作者rpivovar

