Kickstart vs Ansible Tower

Latest response

I am needing to make RHEL iso of the same image for multiple computers. Would it be better to create a kickstart image or to create an ansible image of the iso? Which is easier to perform? the image would be hardened using DISA STIGs.

Responses

I don't have much experience with Tower so I'm pretty biased, but I use a kickstart for this with a modified iso that has extra packages, background pictures, etc. A lot of my systems are standalones so this method has been easier for me

Hi Alexander,

Tower is apparently a good product for those who haven't had experience in the weeds for non-Tower Ansible. If you need something in a hurry, examine the RHEL edition of Frank Caviggia https://github.com/fcaviggia. That being said, you'll really want to read over his kickstart and how it works.

Frank Caviggia is a former Red-Hatter who came up with a stand-alone stig product for Red Hat (and CentOS (see above link).

Immediately upon install, his ISO will open a menu.py file. You'll partition off the drive using mere percentages (a little annoying, however, bear with this). Know that there are things like specific groups defined to disallow ssh except for those in a specific group membership. Know that there are certain files that have been made immutable with things like the "chattr -i /etc/selinux/config" - which is a bit heavy handed. You may or may not find usbguard useful. I got it out of the way, however the program does have merit if you really to go down that path... You'll have to know about usbguard if you wish to move data or files via any USB storage device.

I found his banner (for desktops) config file had to be hand-coded afterwards (I put a note at his github on that) because it didn't accept hex codes and render the banner correctly. There are a few other things that might hit you, such as not being able to directly "su - " but you must use "sudo su -" from the account named "admin" (remember this). Also, Frank kills off your /root/anaconda.ks file in the kickstart so comment out that line in his kickstart that runs the rm command to kill of that resultant file. (Don't get me wrong, Frank Caviggia is a great guy, wrote some great stuff, it's just that some of it is just a little heavy handed, but I admire his pursuit.)

DISA has a rpm for their own DISA stig check... Yes, you can use the openscap, however, be aware that the DISA provided method and rpm uses what DISA expects and it's a bit different. DISA provides the xml file with the latest "STIG definitions" (I'll call them) at their website (use your pki).

There are a number of places that already have scripts for most of the items you'll find. By the way, yes, there are a lot of annoying false positives. In my case, we really were in compliance but it won't rate you as such. One example the DISA provided RPM was not geared to realize that RHEL 7.6 is a supported version of RHEL. And even though they'll probably fix this in July of 2019, I'll bet you one US dollar, or the beverage of your choice, that it will be broken when RHEL 7.7 is released. So things like FIPS when you've dealt with it correctly will show up along with a stack of other things as being non-compliant when in fact it is, simply because you've upgraded to 7.7 (when it comes out of non-beta). We've dealt with this for every minor release.

I personally use kickstarts, and in the kickstart put a line for each script I run for a specific STIG item. It's best if your scripts are made such that if they are ran once, it won't hit the system again. Our scripts now as we write them only run a STIG mitigations only if it hasn't been previously ran. We're adding something where if there's an override for a compelling reason, it won't hit that system.

# this is an excerpt from a kickstart file.  If you are unfamiliar with kickstarts, see Red Hat's kickstart tool at the Customer Portal 
# as a beginning point, or examine a loaded system, the /root/anaconda.ks file that is generated with any RHEL load.
%post
# stig calls to scripts
%include http://192.168.168.168/pub/files/stig/common/cce-22101.bash

%end

That "%include" thing above will bring down and run the script. HOT TIP: if you remember nothing else, remember this Your path to the URL in the example above must be ROCK SOLID downloadable - permissions straight. If it isn't your kickstart will fail for the ambiguous "can't download kickstart file" when the kickstart file is actually fine however, because the URL within the kickstart for the %include is wrong, or it's file on the web server has wrong permissions, it scuttles your entire kickstart.

Yes, you can take Frank Caviggia's method and put all the scripts into a DVD. However, you will find over time that the partitioning for his method - you'll eventually want to harvest off the /root/anaconda.ks file and use that as an initial template where you will tailor the kickstart further. Don't get me wrong, Franks' disk works, however, know of the things I mentioned above, and don't be blind to what the disk does, or I guarantee you frustration.

Sadly, those that go down the path of STIG things have one thing in common. They have to buckle down and go through what does and doesn't work for them. One example, you'll want to really familiarize yourself with auditctl and make a highly tuned audit.rules file. I'm glad you asked why. A gigantic portion of STIG issues come in the annoying hits one by one for audit rules, for every audit rule failure, you get a hit. And there are loads of them. I'd recommend whittling down the errors your receive initially with audit.rules. Franks' audit.rules is a good place to start.

The thing about complying with STIG things is that the benchmark available at DISA's website changes every quarter. Now this quarter, it wasn't too terribly bad, yeah, a few things here and there. But I bring this up to say your compliance today may not be compliant 3 or 6 months from now with each new quarter's (quarter-year) DISA benchmark STIG xml file.

One side note, apart from everything else, for servers, remove the "dconf" package so you don't get hit with fixing gnome issues on a non-graphical server. (recommend strongly against graphical servers, use non-graphical multi-user.target for servers). If you don't have dconf loaded, you'll skip a number of findings.

Some ansible (non-tower) methods to do this are at https://github.com/MindPointGroup/RHEL7-STIG however, read it carefully and it's implementation.

Wish you well

RJ

Good information! I wish I found that github before I finished my kickstart!

For Nathan, I'm assuming you already have experience with RHEL stigs and might already know this, but R. Hinton is correct that it is impossible to get to 100% SCAP rating because of the supported release finding that also ties into fips as well as the banner simply because the SCC check values are not updated/incorrect.

I have never achieved 100% and I dont think I would want to have 100% haha. If I was 100% no work would ever get done. I checked out that site and it seems he hasnt updated it in a while. I wonder if having a playbook that you update with the latest stig would be more beneficial that kickstart in applying updated stigs.

But it does sound like a kickstart image would be the beginning piece and then have ansible maintain.

Do yall agree?

That's what I would do if my systems were all on the same network. I'd keep the kickstart on a server and then add "ks=http://IP/ks.cfg" and "fips=1" if you need fips enabled to the installation options. Obviously change the http to whatever it is you'd use. Then keep them all in line with ansible

I can't think of anyone who realistically does this that ever achieves 100%. Anyone who thinks 100% is achievable (and sustaining server function) has some unrealistic expectations. When I work with customers, we easily achieve over 90% and some servers are above 95%. And in my case, with the various customers I support, there is no lack of function.

I have a FIPS compliance script that takes care of the whole FIPS implementation process that I've published in the Red Hat discussion area that also works with CentOS. The script also ensures that concurrent kernel upgrades will receive the proper FIPS directives in the grub.cfg file.