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

Mechanism for runtime configuration #28

Open
rillian opened this issue Jun 27, 2023 · 0 comments
Open

Mechanism for runtime configuration #28

rillian opened this issue Jun 27, 2023 · 0 comments

Comments

@rillian
Copy link
Contributor

rillian commented Jun 27, 2023

Right now nitriding command-line arguments which regularly vary between deployments, like the fqdn and prometheus ports, are part of the image. That's nice in that it reduces the communications which must be checked in code audit.

On the other hand, it multiplies the number of images whose builds must be verified, even for "trivial" changes like moving the same app version from staging to production deployment.

To address this, the daemon would benefit from a method to obtain (some of) its configuration from outside the enclave.

In many deployment systems this is handled with environment variables, and being able to pass environment variables when starting the wrapped application could be part of simplifying moving a webservice implementation into AWS Nitro enclaves. But that mechanism is not available to the nitriding daemon itself as the first element run inside the enclave.

We've talked about using dns srv records for leader designation and key exchange; that's also a possibility here. Another idea would be to use a service url to retrieve configuration data over https, similar to how many cloud services pass initialization data to deployments.

@brave brave deleted a comment from atifnimran Jul 5, 2023
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

1 participant