4c40b92950
Because buildset registries may be used by jobs that finish before other jobs are finished using the buildset registry we must be careful not to expose the registry credentials in the jobs that finish sooner. Otherwise logs for the earlier job runs could potentially be used to poison the registry for later jobs. This is likely currently incomplete. Other Zuulians should look over it carefully to ensure we're covering all the bases here. The cases I've identified so far are: * Setting facts that include passwords * Reading and writing to files that include passwords (as content may be logged) * Calling modules with passwords passed as arguments (the module invocation is logged) I've also set no_log on zuul_return that passes up credentials because while the logging for zuul_return is minimal today, I don't want to count on it remaining that way. We also use the yet to be merged secret_data attribute on zuul_return to ensure that zuul_return itself does not expose anything unwanted. Finally it would be great if others could check over the use of buildset_registry variables to make sure there aren't any that got missed. One thing I'm not sure of is whether or not when conditionals get logged and if we need to be careful about their use too. Temporarily remove some buildset-regitry jobs which are in a catch-22. Change-Id: I2dea683e27f00b99a7766bf830981bf91b925265 |
||
---|---|---|
.. | ||
defaults | ||
tasks | ||
templates | ||
README.rst |
Runs a container registry for the use of this buildset.
This may be used for a single job running on a single node, or it may be used at the root of a job graph so that multiple jobs running for a single change can share the registry.
Role Variables
Return Values
Information about the registry.
The host (IP address) of the registry.
The port on which the registry is listening.
The username used to access the registry via HTTP basic auth.
The password used to access the registry via HTTP basic auth.
The (self-signed) certificate used by the registry.