GitHub Community
Unable to read Secret set in environment. #172534
-
|
I am experiencing a persistent issue with a GitHub Actions workflow where it is unable to access secrets defined in a protected environment. The workflow consistently fails at the aws-actions/configure-aws-credentials step with the error Input required and not supplied: aws-region, because the expression ${{ secrets.AWS_REGION }} evaluates to null. I am confident this is not a user-level configuration error, as we have exhaustively troubleshot all possible causes. Summary of the IssueWorkflow: A CI/CD pipeline intended to deploy to AWS EC2 using OIDC for authentication. Environment: A protected environment named production is configured. Secrets: All required secrets, including AWS_REGION and AWS_ROLE_TO_ASSUME, have been correctly created within the production environment's secrets settings. Error: The workflow fails because it cannot read any of the secrets from the environment. Debug logs clearly show that the secret values are null when the action runs. Troubleshooting Steps Already TakenWe have systematically tried the following solutions without success: Verified the Workflow File: The .yml file correctly specifies the environment: production for the job and references the secrets using the correct ${{ secrets.SECRET_NAME }} syntax. Confirmed Permissions: The job has the necessary permissions block with id-token: write and contents: read. Verified IAM Trust Policy: The AWS IAM Role's trust policy for the OIDC provider has been verified and correctly references our repository (repo:my-org/my-repo:*). Checked Environment Protection Rules: We disabled all deployment branch restrictions for the production environment to ensure there were no authorization issues. Created a Minimal Test Case: We created a brand new, minimal workflow file (debug.yml) that does nothing but attempt to configure AWS credentials. This test case failed with the exact same error, proving the issue is not with the complexity of our original workflow. (I will share the log below.) The problem persists despite all settings appearing correct. The workflow seems unable to access the production environment's context and its associated secrets. 2025-09-06T04:54:06.5881713Z Current runner version: '2.328.0' |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
|
I ran into this issue before — the root cause is usually that environment secrets are only available after the job declares the environment. If the workflow tries to read them before that, they will show up as Here are the main things to check: 1. Set the environment at the job levelMake sure your workflow looks like this (not at the top-level jobs:
deploy:
runs-on: ubuntu-latest
environment: production # this activates the environment
permissions:
id-token: write
contents: read
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-region: ${{ secrets.AWS_REGION }}
role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}2. Verify where the secrets are storedGo to Settings > Environments > production > Secrets. Confirm Secrets stored only at the repo level won’t work if you reference an environment. If you created them with the CLI or Terraform, make sure you scoped them correctly: gh secret set AWS_REGION --repo OWNER/REPO -e production3. PermissionsYou already have id-token: write and contents: read, which is correct for OIDC. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the answer. |
Beta Was this translation helpful? Give feedback.
-
|
Ok i can check for another one |
Beta Was this translation helpful? Give feedback.
-
|
if you’ve already confirmed the environment is set at the job level, the secrets really live under that environment (not just repo-level), and permissions are fine, then normally ${{ secrets.AWS_REGION }} should resolve. A couple of sneaky things I’ve seen cause this:
|
Beta Was this translation helpful? Give feedback.
-
|
Self-answer This stemmed from a very basic misunderstanding when using GitHub Actions for the first time. I assumed the name in the Add Secret modal was the secret's name, so I entered the value in multiple lines, as shown below: Now that I've mapped the key-value pairs one by one, there's no problem. |
Beta Was this translation helpful? Give feedback.
Self-answer
This stemmed from a very basic misunderstanding when using GitHub Actions for the first time.
In the Add Secret modal, the name was the key, and I needed to enter a value corresponding to that key.
I assumed the name in the Add Secret modal was the secret's name, so I entered the value in multiple lines, as shown below:
Now that I've mapped the key-value pairs one by one, there's no problem.