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

Environment Variable Resolver #254

Merged
merged 12 commits into from
May 17, 2022
Merged

Environment Variable Resolver #254

merged 12 commits into from
May 17, 2022

Conversation

ncilfone
Copy link
Contributor

@ncilfone ncilfone commented May 16, 2022

What does this PR do?

This adds a resolver for environment variables thus allowing the definition of simple spock parameters with the following syntax: ${spock.env:value, default} -- this will read the value from an env variable and fall back on the default if given. Currently supports only simple python types: float, int, string, bool (there are no future plans to support complex types as value and type resolution would require significant effort)

Additionally, this PR also implements the ability to annotate these resolvers. Currently implemented are inject and crypto.

Inject

This will 'inject' the original env variable definition back into the saved spock state when writing to file. For instance, if a parameter is defined as with the inject annotation (by adding .inject to the env annotation):

class Example:
    one: Optional[int] = "${spock.env.inject:DUMMY}"

DUMMY will be read from the environment variable and set to its actual value within the Spockspace, however when written to file instead of the read value being written, the original syntax will be written instead (thus still referencing the env variable and not fixing the value):

Example:
  one: ${spock.env.inject:DUMMY}

Crypto

Sometimes these env variables or other given variables within a spock config might be sensitive information (i.e. a lot of cloud infra uses env variables that might contain passwords, internal DNS domains, etc.). Therefore, the crypto annotation (by adding .crypto to a resolver) provides a simple way to hide these sensitive variables while still maintaining the written/loadable state of the spock config by using the cryptography package (via a salt and key) to 'encrypt' these sensitive values and prevent them from being stored in plaintext.

For instance, here you can add the .crypto annotation to the spock.env notation to indicate that this variable should be 'encrypted' when writing to file.

@spock
class Example:
    two: Optional[str] = "${spock.env.crypto:DUMMY,Foo}"

Producing...

Example:
  two: "${spock.crypto:gAAAAABiesGutuzXLyE-jICdI3gFANcWydM2MhK9-WmB73wi4daP38gu1jmlCv-FjiP54Mv9cqT5YQdMn4qFrRg32-wzeZmOYAAm5uKmBXHWx6pxa70BO8c=}"

This will also dump a *.spock.cfg.salt.yaml *.spock.cfg.key.yaml to file with the same UUID which can be used to 'decrypt' these values within python code.

The SpockBuilder class now takes key and salt arguments which can be paths to the salt and key yaml files, direct values of the key (ByteString) and salt (string), or env resolvers to the salt and key (e.g. '${spock.env:SALT}') which will automatically 'decrypt' the values when building the Spockspace

Partial implementation of discussion in #243.

Bonus addition, saving the spock config with the extra_info flag now dumps all the currently installed packages within a commented block at the end of the file.

Checklist

  • Did you adhere to PEP-8 standards?
  • Did you run black and isort prior to submitting your PR?
  • Does your PR pass all existing unit tests?
  • Did you add associated unit tests for any additional functionality?
  • Did you provide documentation (Google Docstring format) whenever possible, even for simple functions or classes?

@coveralls
Copy link

coveralls commented May 16, 2022

Pull Request Test Coverage Report for Build 2333348687

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

Details

  • 220 of 319 (68.97%) changed or added relevant lines in 13 files are covered.
  • 16 unchanged lines in 2 files lost coverage.
  • Overall coverage decreased (-3.5%) to 92.139%

Changes Missing Coverage Covered Lines Changed/Added Lines %
spock/backend/spaces.py 7 8 87.5%
spock/backend/saver.py 16 19 84.21%
spock/backend/utils.py 3 9 33.33%
spock/handlers.py 36 49 73.47%
spock/builder.py 33 49 67.35%
spock/backend/field_handlers.py 28 46 60.87%
spock/backend/resolvers.py 57 99 57.58%
Files with Coverage Reduction New Missed Lines %
spock/builder.py 3 92.78%
spock/backend/field_handlers.py 13 86.07%
Totals Coverage Status
Change from base Build 2240354546: -3.5%
Covered Lines: 2145
Relevant Lines: 2328

💛 - Coveralls

@ncilfone ncilfone merged commit 6c2cadc into master May 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants