Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

quality of life: when duplicate a job, don't redact environment variables in task if it inherit from input #337

Open
v36372 opened this issue Feb 20, 2024 · 3 comments

Comments

@v36372
Copy link
Contributor

v36372 commented Feb 20, 2024

Hi, when I duplicate a job, the task environment variables that are matched with secret pattern will be replaced its value with "[REDACTED]", even if it only inherit the value from inputs

For example:

name: Example
inputs:
  SECRET: 12345
tasks:
  - name: Example
    run: |
      echo "hello world"
    image: python:3-slim
    env:
      SECRET: "{{ inputs.SECRET }}"

When duplicating this job, it's definition become

name: Example
inputs:
  SECRET: "[REDACTED]"
tasks:
  - name: Example
    run: |
      echo "hello world"
    image: python:3-slim
    env:
      SECRET: "[REDACTED]"

The second redaction is unnecessary.

@runabol
Copy link
Owner

runabol commented Feb 21, 2024

This is due to your environment variable named SECRET. A quick fix would be to rename it to something else. That being said, I do plan on adding a top level job secrets construct to house all secrets, so I never have to redact anything within the job but only that section.

@v36372
Copy link
Contributor Author

v36372 commented Feb 26, 2024

My intention is to redact everything. I have the secret pattern config like this:

[middleware.job.redact]
enabled = true
patterns = ["*"]

But that is not relevant to the point I'm making. I'm just proposing that maybe don't redact the variables whose value is inherited from inputs, because it's not the actual content anyway.

@runabol
Copy link
Owner

runabol commented Feb 26, 2024

Parsing the value has too many edge cases. Example:

{{inputs.not_a_secret}}/actual_secret

So if I don't redact this it will have the secret in the clear.

That's why I'm thinking of adding a new secrets construct that will be more explicit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants