I have a bunch of example content related to creating docker containers using bigfix and running the bigfix client within docker containers. This is early work, intended primarily for testing.
BigFix is definitely useful on docker hosts, as long as the host in question can run bigfix.
If there is a bigfix agent for the base OS of a docker container, then bigfix should be able to run within it and help manage it. If it is a docker container that will only exist for a very short time, like under a day, then BigFix is probably not the best solution since it will create a lot of computer records and overhead for the server, but otherwise, I think BigFix is useful within docker containers, especially those that are not being used as immutable and are instead being used more like a traditional VM. It may not be the most modern way to handle things, but if you are doing it anyway, then BigFix can help.
@jgstew - We have a requirement to manage the container host OS through bigfix for patching. We do not have access to host OS - we can not install bigfix agent in host OS. Can we have any solution with privileged containers? Is there anyway to install patches to host OS through privileged containers?
It looks like privileged containers might allow this kind of access, https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities, but you’d have to test to confirm. It certainly seems odd to manage a host this way. If they’re going to give you access to do anything to the host from a container, why wouldn’t they just give you access to the host?
This is a good point, since they are effectively equivalent levels of access.
That said, some Docker Host OSes don’t allow installation of software on them in the traditional sense and instead handle this through containers, to the point where some of the OSes are actually made up of multiple privileged containers.
BigFix running in a Privileged Container would allow BigFix to access the host, but I don’t believe it actually looks like BigFix is running on the actual host OS, it just has access to it. This should mean that traditional bigfix patch fixlets would appear relevant based upon the Privileged Container and not the Host OS itself.
I have been meaning to test Privileged Containers for this kind of use to see how they work, but I have never actually tested this.
Thank you for the responses.
Even I doubt that the bigfix agent may be only installed in privileged container with access to host OS. Please let me know the result if you are testing it.
Will there be any solution around it from product team itself? I believe that some of the management tool vendors are working on providing privileged container images.
Do you know what Docker Host OS is being used in the specific use case you have in mind?
The ability for BigFix to run in a privileged container that is not itself an OS container would require that it at least be in the same family as something that BigFix would support directly.
Not likely anytime soon, though technically, anyone could make a proxy agent for this without any support from IBM/BigFix.
The trick with running relays inside of containers is that the Docker host can only expose the relay port (52311) to a single container unless using a load balancer to pass traffic to a single port to many containers on the same host in a sticky way. This load balancing option is possible using Docker Swarm. I have not tested this myself… yet.
Hi @jgstew, I pretty much have very similar relevance to https://bigfix.me/relevance/details/30203708 (I just added the windows counterpart folder “C:\ProgramData\docker\containers”) but the problem I’ve been finding recently is that in some cases docker containers are installed in customized file structures, especially if they user overlay networking - for the latter as an example, I see dockers in */docker/overlay/. Have you looked into automatically detecting container install paths instead of hardcoding it?
That is possible with relevance. Do you have example full paths and where you might look them up in the registry or config file?
You can write relevance to check for things within a folder without knowing the name of it so example would be: C:\Users\USERNAME\Desktop or C:\Users\*\Desktop you would write in relevance as: folders "Desktop" of folders of folders "C:\Users" where folders of folders "C:\Users" returns all subfolders of folders "C:\Users"
Yea, unfortunately, those are all over the map and seems to be imported from other providers/software as well, so don’t think any kind of relevance magic can be done. I was hoping there was something on docker global conf that be read to identify all paths… Pulled a few locations that I found dockers running out of: