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

[Feat]: Extensibility for the environment attestor #275

Open
joshdabosh opened this issue Jun 12, 2024 · 5 comments
Open

[Feat]: Extensibility for the environment attestor #275

joshdabosh opened this issue Jun 12, 2024 · 5 comments
Labels
feature New feature (larger than enhancement)

Comments

@joshdabosh
Copy link
Contributor

Describe the solution you'd like:
A way to add environment variables to the default denylist, or a way to optionally only attest a specified list of environment variables.

User value:

Some environments may have sensitive information stored in environment variables which are not covered in the denylist now. Using the environment attestor will store them in recoverable plaintext in generated attestations.

Expected behavior:

Environment variables can be selectively denied or allowed to be attested.

Proposed solution:

Add a flag to decide between allowlist / denylist, and another flag to append to either list for later filtering.

Anything else you would like to add:

Testing changes required:

Add tests to make sure environment variables are correctly filtered.

Documentation changes required:

Add flags to the CLI reference and modify the Environment attestor page.

@matglas
Copy link
Contributor

matglas commented Aug 1, 2024

This would be very valuable to have!

Some suggestions/options:

  • Your own list of allowed variables.
  • List of variable to obfuscate. Where the name is captured but values is *** by default.
  • Using glob matching to do *_TOKEN or *_TOKEN_* to deny them.

@jkjell maybe this could have a feature label.

@jkjell jkjell added the feature New feature (larger than enhancement) label Aug 30, 2024
@jkjell
Copy link
Member

jkjell commented Aug 30, 2024

One thing for future conversation about this is what to do with environmental variables that modify the behavior of a process. If someone decides to compile a program with ENABLE_INSECURE_BEHAVIOR=1 but, has a DENY * config for the environment attestor, a policy could still need to be able to verify the presence or absence of that flag. This is a long way of saying we'll probably need to include the config options of the attestor in the attestation itself.

@matglas
Copy link
Contributor

matglas commented Aug 30, 2024

we'll probably need to include the config options of the attestor in the attestation itself.

Agree. I think this is something that all attestors should have.

@matglas
Copy link
Contributor

matglas commented Aug 30, 2024

Would a PR that protects vars by hidding the value be a good first step?

@matglas
Copy link
Contributor

matglas commented Sep 26, 2024

@joshdabosh please see the PR and the conversation that is happening there. Curious to hear your thoughts on proposed enhancements there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature (larger than enhancement)
Projects
None yet
Development

No branches or pull requests

3 participants