ArcSight Smart Connector docker container

Idea ID 2705646

ArcSight Smart Connector docker container

ArcSight Smart Connector docker container suitable for environments that are not supported.

6 Comments
Knowledge Partner Knowledge Partner
Knowledge Partner

@Ionut Daniel Mosoiu , like that one i created for 7.11 some time ago?

https://github.com/AVitg/Dock-ArcSight-SC

Acclaimed Contributor.
Acclaimed Contributor.

Similar but something supported by MF.

Micro Focus Contributor
Micro Focus Contributor
Status changed to: Waiting for Votes

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?

 

 

Honored Contributor.
Honored Contributor.

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.

Knowledge Partner Knowledge Partner
Knowledge Partner

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

Honored Contributor.
Honored Contributor.

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.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.