Open evandena opened 1 year ago
Hmm, that's tricky. Is there any host where you could push the RPM where it is accessible by either HTTP (not TLS), or HTTPS such that the network path bypasses or is exempted by the firewall, and where the network path allows the instance to reach the host? That's how we do it, when building images that require custom certs. Basically just host the RPM with the certs somewhere the instance can actually download it, and specify it as the first package in the amgien8_extra_rpms
argument. It gets downloaded by yum, installed, and then the certs are available for everything else.
Thanks for the response @lorengordon. That's definitely an option, and probably the easiest one to implement, but I can imagine an internal scan finding an insecure webserver and that causing some misguided issues.
Maybe I could look into terraform building an s3 bucket in the pipeline and destroying it after the spel build.
An option we use on our post-spel EC2 builds is to add the certs in the cloudinit user-data, but I'm trying to solve the spel problem with little (if any) spel code modification. We're already doing a handful of sed commands in our pipeline against the minimal-linux.pkr.hcl, but solving the cert issue would be more involved.
I assume you're using this cloud-init module to update certs?
We hadn't considered a mechanism to further customize the build quite like that, but I can understand the use case. It would need to be optional, of course. I can see a few ways to get there:
templatefile()
function to inject the values, with a list of certs as a new input. That will work for the builders, but that won't get the certs into the resulting images. But, if you also host the rpm via HTTPS you could pass then pass the url via amigen8_extra_rpms
.Worth noting that, at least in the meantime, you can bootstrap from arbitrary AMIs. You could select a customized AMI that was the same as the one(s) you're currently selecting but for having baked-in the requisite certs. That would get you past the git
errors (and then use the amigen8_extra_rpms
var to also bake your site's private certs into the spel-built AMI(s). Effectively, this is what's done by other user of spel that have similar SSL-validation-breaking security-appliances.
@evandena Would you be interested in working on a PR that implements a solution for this use case? I don't really see us getting to it any time soon... But if you open a PR that works for you, I'll be happy to review it and provide feedback and get it merged.
Expected behavior
Option to install a local RPM in the spel build box.
Actual behavior
From packer:
This is due to our MITM firewall and a base RHEL OS not trusting our internal certificate.
Suggestions for fix
Is there an easy way to specify a local RPM to install during the build? We could easily bundle up our internal certificates as an RPM. I see the EXTRARPMS variable, but it appears that's just doing a yum install.
It would be neat to be able to provide a local RPM and have packer push it to the build box, and one of the spel processes be able to install it.