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
{{ message }}
This repository has been archived by the owner on Mar 22, 2021. It is now read-only.
Right now, there's no support for provisioning RHEL-based hosts/containers and registering them. By its very nature, redhat-ci is more targeted at upstream work, which usually means Fedora/CentOS anyway. Though there could be use cases for provisioning RHEL userspaces too.
I've been avoiding this because I didn't want to deal with the risk factor of leaking subscription data, though there might be safe ways to do this, e.g. creating temporary stage accounts that last the duration of the test run.
The text was updated successfully, but these errors were encountered:
Perhaps the duration of the subscription only lasts until build/test commands start. In other words, package install is permitted, but then the system is unsubscribed and unregistered. Then the only place it's possible to run commands (that could expose the subscription or host certs) is from a script embedded in an RPM. However, those certs. would soon be invalidated when the packaging section ended (or there was an error or timeout).
Otherwise, the only thing you need to protect is any logs of the 'subscription-manager' command itself. That's easily done by feeding it's --username, --password, and --org parameters with values from short-lived files or env. vars. Then, to be safe, kill root's .bash_history (from a separate shell).
I think there's even a subscription-manager "reset" option that will wipe out all traces of the system's cert. Combine all that with your short-lived credentials idea, and there's multiple-layers of protection against leaks.
Right now, there's no support for provisioning RHEL-based hosts/containers and registering them. By its very nature, redhat-ci is more targeted at upstream work, which usually means Fedora/CentOS anyway. Though there could be use cases for provisioning RHEL userspaces too.
I've been avoiding this because I didn't want to deal with the risk factor of leaking subscription data, though there might be safe ways to do this, e.g. creating temporary stage accounts that last the duration of the test run.
The text was updated successfully, but these errors were encountered: