You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: