Yes that kind of aspects should be addressed, such as credential management, PVCs, ports, connectivity against the remote destination, etc. The images should be hosted on your private container registry. 

If ArcSight MC can provide a fully DSC I'm fine but AFAIK, it's not the case. You can define some policies there but it has limitations and it's a pain to maintain them .. while if you have your image on your own repo you apply central changes directly there and trigger the desired automation you want to. 

Container for each type are needed, depending on your needs you use either one type or another, then the config of each one varies - as well the definition of the underlying silent config file used on the image definition. 

Your approach to have just the base sw containerised might be valid but it requires a fully ArcMC management and you lost the real DSC.

Tbh.. i think I would prefer code to build my own containers before I use containers from a repo. Maybe I need some specifics here and there... A certain SC version, you name it.. however I would like to see some thoughts on persistent volumes etc, because I don't want to loose my config after each container restart... for the pic it was not needed but for prod, for sure.

Containers for each type? No means... Expose remote management port and configure the SC with ArcMC to your needs, easy like that. 

KR

A

Hi,

I'd say that the goal would be to have an official supported Docker Container Image provided by MF that contains the arcsight agents - for every single type.

There are lots of vendors that are already doing this, take a look on the docker hub: https://hub.docker.com/search?q=oracle&type=image

In tech terms, this is possible - on the last Protect17 we have a session: "Containers are everywhere, even on ArcSight SmartConnectors" that gave us the idea. I have personally tested and works.

The thing would be to have it for all the agents type - currently I've just performed for a couple of types with certain destinations already configured. Since this requires automation, the only solution that comes to my mind were silent install config file as part of the Docker manifest. 

Once the images are created, we'd just have to pull them from the container registry and deploy wherever we want to, i.e. bare server, VMs, K8s clusters ... and no longer installing and maintaining the traditional services installed on our VMs. 

Those images can be even part of a CI/CD pipeline, that would enable version history, tracking and automation for deployment .. this is out of the scope - just thinking loudly about the possibilities - which are not just portability and agility. 

Hope that this clarifies the idea behind.

regards,

Karl.

Please elaborate with more specifics on exactly what you would like this Connector to monitor.  

It is difficult to interpret what the phrase "... suitable for environments that are not supported.' pertains to.  Can you provide concrete examples?

Similar but something supported by MF.