Akamai Guardicore Segmentation Installation Guide

Centra 5.
0
V40
Installation Guide
Guardicore Centra Installation Guide
0.1 Table of Contents

0.1 Table of Contents 2
0.2 Revisions Record 14

Revision Procedure: 14
0.3 Revisions Highlights 15
0.4 Supported infrastructure 16
Guardicore Centra Security Platform 17
About this Manual 17

For Whom this Manual is Intended 17
How to use this manual? 18
1.1 Centra Architecture 19
1.2 Deployment Overview 20

General Installation Logic 20
1.3 Deployment Preparations 22

1.3.1 Required image files 23
1.3.2 AIO- Computation Requirements 24
1.3.3 Distributed Management Cluster- Computation Requirements 27
1.3.4 Connectivity Requirements Diagram 31
2.1 Vmware installation 32

2.1.1 On-Premises Configuration (AIO) 33
2.1.2 On-Premises Distributed Management Configuration 42
Provision the Machines and Create an IP-plan 42
Deploy VMs from OVAs and Configure Networking 42
Preconfigure the Management Cluster Nodes 46
Configure the Management Cluster 48
Run the Setup Wizard 48
Adjust ElasticSearch cluster heap size 57
© 2021 Guardicore LTD. | 2
Proprietary and Confidential

Configure RabbitMQ Redundancy Cluster 58

Configure MongoDB HA Cluster 59
Stage 1: Check Prerequisites 60
Stage 2: Initialize the Replica Set 60
Stage 3: Add Members to the Replica Set 61
Stage 4: Start the Cluster 63
2.1.3 Deception Server deployment 64
2.1.4 Collectors deployment 69
2.1.4.1 ESX Collectors deployment 70
Manual Deployment of ESX Collectors 70
Advanced Setting Configuration 73
Automatic Deployment of ESX Collectors using the Collector Deployment Tool 76
2.1.4.2 SPAN Collectors Deployment 79
Connectivity 79
SPAN Collector Installation Procedure 80
2.1.4.3 IP Flow Collector Deployment 88
Connectivity 88
2.1.4.4 Collector Appendices 95
2.1.4.4.1 Collector Appendix A: How to create DRS rules to fix ESX Collectors to hosts
95
How to create DRS rules to fix ESX Collectors to hosts using the vSphere Client 95
How to create DRS rules to fix ESX Collectors to hosts using the vSphere Web
Client 97
2.1.4.4.2 Collector Appendix B: Create a SPAN Network port 100
Create a SPAN Network port for the ESX Collector using Vsphere Client 100
Create a SPAN on a standard vSwitch 100
Create a span on a dvSwitch 101
Create a SPAN Network for the ESX Collector through Vsphere Web Client 103
Create a span on a standard vswitch 103
Create a span on a dvSwitch 105
Create a SPAN port on n1kv 107
2.1.5 Aggregator(s) deployment 110
Create FQDN(s) Record 110
Deploy Aggregators 111

Mega Aggregators 119
2.2 AWS Centra installation 121

2.2.1 AWS Configuration and Preconditions 122
Creating a VPC (an isolated portion of the cloud for AWS objects): 123
Creating a Subnet within the VPC (similar to a VLAN): 124
Creating Internet Gateway 125
Creating Security Groups 126
Create a Key-Pair to access your instances 127
2.2.2 Management Server deployment- AIO 129
Step 1 - Launch an EC2 instance for the Management server 129
Step 2 - *Optional* Generate an Elastic IP and associate it with the Management 132
Step 3 - Connect to the Management and validate connectivity 133
Step 4 - Configure the Management software 134
2.2.3 Aggregator server deployment 138
Step 1 - Launch an EC2 instance for the Aggregator 138
Step 2 - *Optional* Generate an Elastic IP and associate it with the Aggregator 142
Step 3 - Connect to the Aggregator and validate connectivity 143
Step 4 - Configure the Aggregator software 143
2.3 Hyper-V installation 151

2.3.1 Deployment procedure 152
Deploying vhd Deception Server 165
2.3.2 HyperV components installation 167
2.3.3 On-Premises Configuration (AIO) 168
2.3.4 On-Premises Distributed Management Configuration 177
Provision the Machines and Create an IP-plan 177
Deploy VMs from VHD and Configure Networking 177
Preconfigure the Management Cluster Nodes 181
Configure the Management Cluster 183
Run the Setup Wizard 183
Adjust ElasticSearch cluster heap size 192
Configure RabbitMQ Redundancy Cluster 193

Configure MongoDB HA Cluster 193

Stage 1: Check Prerequisites 195
Stage 2: Initialize the Replica Set 195
Stage 3: Add Members to the Replica Set 196
Stage 4: Start the Cluster 197
2.3.5 Deception Server deployment 199
2.3.6 Aggregator(s) deployment 203
Create FQDN(s) Record 203
Deploy Aggregators 204
2.4 Azure installation 213

2.4.1 Preconditions 214
2.4.2 Installation steps 214
2.4.2.1 Upload VHD of the Aggregator to Azure platform using Microsoft Azure Storage
Explorer 214
Connect to Azure Subscription 214
Upload the VHD to a managed Disk 217
Troubleshooting 219
2.4.2.2 Create a VM from the VHD 220
Create the VM 221
Basics 222
Disks 223
Networking 224
Other 225
2.4.2.3 Connect to the Aggregator and validate connectivity 226
Connect to the Aggregator via SSH and validate connectivity 226
Troubleshooting SSH not working (Skip to step 4 if SSH worked) 227
2.4.2.4 Configure the Aggregator software 230
2.5 GCP Installation 238

2.5.2.1 Create a VM from the image 239

2.6 OCI Installation 248

2.6.2.1 Creating the Centra VMs 250
3.1 Overview of Agent Installation Steps 259
3.2 Checks to Perform BEFORE Deployment 260

Verify communication between Agents and Aggregator 260
Verify OS support 260
Verify Available Storage Space on the Server 262
Installation Profile Configuration 262
Overview 262
Installation Profiles List 263
Default Installation Profile 264
Create a New Profile 264
Agent Installation 266
Install Windows Agent with an Installation Profile 266
Install a Linux Agent with an Installation profile 267
Edit an Installation Profile 267
Reset Configuration to Profile 267
3.3 Manual Deployment of Agents Using the Admin GUI 269
3.4 Introduction to Agent Installation 272
3.5 Windows Agents Installation 272

Windows Agents - Online Installation 273
Installation Script 273
Advanced installation parameters 273
Expected Result 274
Possible Installation Errors 274
Windows Agents - Offline Installation 275
Expected Result 275

Windows Agent - Dependency Packages 276

Windows Agent - Post Installation Validation and Troubleshooting 276
Windows Agent Uninstall 278
Windows Agent Upgrade 278
Windows Agent Directory Structure 279
3.5.2 Windows Agent Deployment via PowerShell 280
Requirements: 280
Preparation/Prerequisites 280
Instructions and Steps 280
Arguments 280
Execution: 280
Actions: 281
Script File for Download 281
3.6 Linux Agents Installation 283

Linux Agents - Online Installation 283
Parameters 283
Expected Result 284
Possible Installation Errors 284
Linux Agents - Offline Installation 286
Advanced installation parameters 286
Linux Agents - Post Installation Validation and Troubleshooting 287
Linux Agents Uninstall 289
Linux Agent Upgrade 289
Linux Agents Directory Structure 290
3.7 AIX Agent Installation 291

Supported AIX OS Versions 292
AIX Agent Installation Prerequisites 292
Configuring the Enforcement Mechanism: IPFilter 293
IPFilter Installation 293
AIX Installation and Uninstall 294

Online installation using wget 294

AIX Upgrade 294
Offline Installation Parameters 294
Advanced Offline Installation Parameters 295
Uninstall 296
AIX Agent Files Location 296
3.8 Solaris Agent Installation 297

Supported Solaris OS Sub-Versions 297
Solaris Agent Prerequisites 297
Configuring the Enforcement Mechanism: IPFilter 298
Solaris 11.3 and below - IPFilter 298
Solaris 11.4 - Packet Filter 298
Agents Deployed on Solaris Zones 299
Global Zone 299
Shared-IP Non-Global Zone 299
Exclusive-IP Non-Global Zone 299
Global Zone with NAT Configurations 300
Installation and Uninstall 300
Online installation using wget 300
Installation Parameters using wget 300
Advanced Installation Parameters using wget 302
Online Solaris Agent Installation Using local Files 302
One time preparations: 302
On the Solaris server: 303
Installing an Agent with enforcement module disabled on Solaris 11.4 304
Uninstall 304
Solaris Agent Files Location 304
Customizing Agent Installation 305
3.9 Docker Native Agent Configuration 306

Prerequisites 306
Setting up Container configuration in Centra 306
3.10 Kubernetes Deployment 307

Known Issues: 308

Validate Customer’s K8s Spec Is Supported: 308
Prerequisites: 308
Firewall Requirements 308
Aggregator Accessibility Check 308
Additional Files (receive from Guardicore Support) 309
Kubernetes Orchestration Configuration 309
Create user and role on the Kubernetes cluster 309
Configure Orchestration in Centra 311
Agent Deployment 313
Custom Container Registry Support 313
Helm deployment 316
Online deployment 318
Offline deployment 319
Agent Uninstall Instructions 319
Helm uninstall 320
Manual uninstall 320
3.11 Automatic Agent Deployment 321

Deploy Agents on Linux servers using Ansible 321
Deploy Agents on Windows Servers Using SCCM 322
Deploy Agents on Windows Servers Using Psexec 323
3.12 Agent Deployment Verification 323

Use the Agent Installation Process Output 324
Use the Agent Screen to View the List of Installed Agents 324
3.13 Installing Agent Log Rotation Profiles 328

Available Profiles 328
Installation Configuration for Agent Log Rotation 328
Installation for Agent Log Rotation on Windows 329
Installation for Agent Log Rotation on Linux/Solaris/AIX 329
4.1 Orchestrations 330

4.1.1 VMware Orchestration configuration (vCenter integration) 330
4.1.2 AWS Orchestration 332

Intro 332
Preconditions: 332
Managing AWS Access: 332
EC2 IAM Role: 332
Guardicore Delegate Access: 332
AWS Policy definition: 333
Starting AWS Orchestration Configuration: 334
Configuring AWS Authentication: 334
Configuring EC2 IAM Role Authentication: 335
Configuring Guardicore Delegate Access Authentication: 336
Configuring Customer Credentials Authentication: 336
Creating an AWS IAM role: 336
Orchestration Information Appears On the Assets Page: 337
4.1.3 Azure Orchestration 338
Intro 338
How to Configure Azure Orchestration 338
Configure a read-only user in the Azure account 338
Add permissions to application user 338
Configure Azure orchestration in the Centra management 338
Important notes 339
4.1.4 GCP Orchestration 340
Intro 340
Configuring GCP Orchestration 340
Step 1: Set Up a Read Only Service Account in GCP 340
Step 2: Add GCP Orchestration to Centra 341
4.1.5 OCI Orchestration 343
Intro 343
Configuring OCI Orchestration 344
Step 1 - In OCI, create an orchestration user for Centra 344
Step 2 - In Centra, configure the OCI orchestration 345
4.1.6 Openstack Orchestration 347
Setting Up OpenStack Orchestration 347
Step 1: Configure a read-only user on the OpenStack platform 347

Step 2: Configure OpenStack Orchestration in Centra 347

Basic Configuration 350
Advanced Configuration 351
API Commands 353
4.1.7 Active Directory Orchestration 355
4.1.8 Inventory API Orchestration 358
Note: Inventory API Orchestration v2.0:
The new and upgraded version of the inventory api (v2.0) is available as well, and the
instructions for setting it up are the same. The original version is still supported but it’s
main usage is for existing environments that are already configured to work against the
previous version. We strongly encourage you to use the v2.0 if you are setting up a new
environment.
Note that the orchestration configuration is the same, except for the REST call itself.
The new API version accepts MAC addresses while the original version does not. 358
When to use the Inventory API? 358
Why Use the Inventory API? 359
How it works 359
Configure the Inventory API 359
REST API Example- v1.0 363
REST API Example- v2.0 365
Limitations 367
4.2 Exportables Configuration 369

4.2.1 Syslog 369
Configuring Syslog Export 369
Events Syslog Exporter 372
Network Log Syslog Exporter 377
Common Event Format (CEF) sent by Centra 378
Enabling the Network Log Reporter 379
4.2.2 Email 379
SaaS Users 380
On-Premises Users 381
4.2.3 Slack 384
4.3 Integrations 384

4.3.1 Integration with Palo Alto Networks Firewall 385

How It Works 385

Before You Begin: Requirements for Successful Integration 386
Configuration 387
Troubleshooting 392
4.4 Authentication And User Management Configuration 394

4.4.1 LDAP SSO 394
4.4.2 Create Kerberos Authentication in Centra 397
Step 1: Create a Keytab File 397
A: Create the User 397
B: Create the Keytab File 399
Step 2: Configure Centra 400
Step 3: Test the Configuration 404
4.4.3 Azure AD SAML 2.0 SSO 405
Stage 1: Configure Azure AD SSO 405
Stage 2: In Centra, configure an AD Azure User Directory 407
Stage 3: Finishing the Configuration in Azure 409
Configure a memberOf claim for SAML 2.0 SSO with Azure AD 411
4.4.4 OKTA SAML 2.0 SSO 414
Step 1: Configure the Okta Guardicore App 414
Step 2: Configure the User Directory in Centra 420
Step 3: Configure the Okta group in Centra 424
4.4.5 Red Hat SAML 2.0 SSO 426
Stage 1: Configure the Identity Provider (IdP) 427
Stage 2: Configure the Service Provider 434
Stage 3: Configure the Encryption Key 435
4.4.6 FortiAuthenticator SAML 2.0 435
Stage 1: Configure SSO and IdP settings in FortiAuthenticator 437
Stage 2: In Centra, configure a User Directory for FortiAuthenticator 438
4.4.7 Permission Schemes 440
Why Create Permissions? 441
Create a Permission Scheme 441
Roles Based Permissions to Centra's Features 445
Scoped Application Owner Role 450

Assign a Permission Scheme to a User 451
4.5 Centra Additional Configurations 453

4.5.1 KO Cloud Connection 453
Background 453
Preparation/Prerequisites 453
Steps 454
4.5.2 Monitoring Relay For On-Prem Customers 455
Make a request to monitor an on-prem environment via Grafana monitoring service: 455
After creation, receive the aforementioned parameters 455
Restart the Telegraf-Relay service 455
4.5.3 Disaster Recovery 455
Guardicore’s Disaster Recovery Solution: How it Works 456
What's synced 456
What's not synced 457
Instructions for Configuring the System for Disaster Recovery 457
Initiating Failover 459
Instructions for Performing a Failback 460
Failback to New Primary 461
Preliminary steps 461
Failback Steps 461
gc-cluster-cli cluster-stop --group all 461
4.5.4 Centra Plugins Server Installation 464
Steps 464
5.1 Appendix A: Agents and OS Support 467
5.2 Appendix B: Management Service Pack update 468
5.3 Appendix C: Security Package Upgrade 469

Prerequisite 469
Procedure 469

0.2 Revisions Record

Date revision Version verification
28.7.2021 1 Initial, v40 Misha Yeverbaum
11.8.2021 2- Installation Guide Addons Misha Yeverbaum
Revision Procedure:
This guide is updated and maintained by the professional services team, thus the updating
procedure is performed by them.
All updates which are required can be inserted into the guide as comments or suggestions and will
be approved by the administrator of the installation guide.
All updates will be recorded in the above section for historical knowledge.
In order to insert an instruction, guide or contect- it is recommended to first contact the PS team
in order for it to be inserted in the proper location and according to the common form.

0.3 Revisions Highlights

1. Revision 2:
a. Incorporated multiple guides from Admin and User guides:
i. K8s deployment
ii. Openstack Orchestration
iii. AWS Orchestration
iv. Azure Orchestration
v. GCP Orchestration
vi. OCI Orchestration
vii. AD Orchestration
viii. Palo Alto Integration
ix. Exportables: Syslog, Email, Slack
x. KO Cloud
xi. Monitoring Relay
xii. AD LDAP configuration
xiii. Kerberos Authentication in Centra
xiv. SAML 2.0 for Okta, Azure AD, Red Hat, FortiAuthenticator
xv. User Directories
xvi. Permission Schemes
2. Revision 3:
a. Incorporated multiple guides from Admin and User guides:
i. Powershell agent deployment
ii. Inventory API Orchestration
iii. DR Deployment
iv. Plugins Server Installation
3. Revision 4:
a. Added Docker Native configuration instaructions.

0.4 Supported infrastructure
Infrastructure Update date Component
VMWare 20.11.2020 Management

Aggregator
ESX Collector
Deception
Hyper-V 20.11.2020 Management

Aggregator
Deception
AWS 20.11.2020 Management

Aggregator
Azure 20.11.2020 Aggregator
GCP 5.7.2021 Aggregator
OCI 5.7.2021 Aggregator
Other 20.11.2020 Span Collector
Other 29.07.2020 IP Flow Collector

1 General Information
Guardicore Centra Security Platform
The Guardicore Centra Security Platform is a comprehensive data center and cloud security
solution that provides a single console for managing segmentation, access control, and security
policies throughout your entire environment. Centra makes visualizing and securing on-premises
and cloud workloads fast and simple. It creates human-readable views of your complete
infrastructure – from the data center to the cloud – with fast and intuitive workflows for
segmentation policy creation.
About this Manual

The manual includes the hardware and software requirements for a successful installation,
instructions for preparing for the installation, downloading the required software, and
deployment.
Note: Disaster Recover (DR) setup is not covered in this guide, although it is mentioned in the
Scaling Architecture section- for general understanding. Consult with Guardicore support for
setting up DR.
For Whom this Manual is Intended
This manual is intended for IT professionals and System Administrators who are familiar with their
infrastructure management systems, be it VMware, HyperV, AWS or Azure.
Windows and Linux operating systems and administration knowledge is required.

How to use this manual?
This guide is divided into different chapters and subchapters.
Chapter no. 2 is dedicated to Centra installation instructions, and includes all platforms currently
supported to deploy the Centra solution on, like VMware, Azure etc.
Chapter no.3 is dedicated to agent installation.
The correct way to deploy Centra is to follow the instructions in chapter 2 which are relevant for
your environment, followed by agent deployment instructions from chapter 3 / agents installation
instructions in the UI.

1.1 Centra Architecture

Guardicore Centra gathers data on flows in your system by deploying several types of software
components: Agents, Aggregators, and Collectors. All of the information is sent to the Guardicore
Management server which provides a single point of control for all data received by the
components. The Management server analyses, enriches, and integrates the data so that it can be
used to provide a clear visualization of information flows in your system, as well as to provide
alerts and enforcement of security policies that regulate information flows.
Here is a brief overview of Centra’s components:
Agents
Agents are deployed on servers in your network and are capable of sending information that
reveals the source and destination of flows, rerouting suspicious flows to the Deception server
(honeypot), and enforcing security policies.
Aggregators
Virtual machines called Aggregators gather and process the data gathered from Agents, and
communicate with the Guardicore Management server.
Collectors
Virtual machines called Collectors gather information on information flows in environments
where Agents cannot be installed.
Management Server
A Management Server receives, analyses, enriches, and manages the collected data.
Deception Server
A Deception Server manages a farm of different-flavored honeypot instances (Windows and
Linux). Failed connections are redirected to a fully interactive honeypot, limiting the attacker’s

interactions to that instance. Following session recording and automatic analysis of its content,
complete incident information is reported to Management.
1.2 Deployment Overview

Guardicore Centra can be deployed in various configurations. The main two distinguishable
options are- SaaS management or On-Premises management.
Within the On-Premises Management option, the system can be deployed on various
infrastructures, which are noted in the revision record of this document.
General Installation Logic

This table describes the general procedure for installing Centra unrelated to the infrastructure it is
deployed on.
Address the correct configuration and perform the tasks as described per infrastructure for your
selected configuration.
Prepare Site
1 Prepare for the Deployment

● Optional - Setup a Guardicore Network.
● Download images if needed, and provision VMs
Installation and Configuration
2 Install Management Server (section 2)

● On-Premise: deploy Management
● Distributed Management: deploy each Management node
● SaaS: Management is in the cloud already
3 Deploy the Deception Server (section 2)

● On-premises and Distributed Management: deploy deception server
● SaaS: already deployed in the cloud.

4 Deploy Collectors (section 2)
5 Deploy Aggregators (section 2)
6 Deploy Agents (section 3)
7 Configure All The Rest Of Required Configuration (section 4 and after)

1.3 Deployment Preparations

Before you deploy Centra components, you must prepare the deployment site. After reviewing the
prerequisites in the previous section, follow these steps:
Step Description
1 Optional: Set-up a Guardicore Network
● Network used by Guardicore components for internal communication.
● Should enable communication between the Management server, Aggregators,
Collectors, Deception server, and Agents.
● Make sure there is communication across the covered hosts. See the Connectivity
Requirements Diagram for details.
2 Download images and provision VMs for Centra Components

Setup dedicated servers for Management (or Distributed Management Cluster), Deception,
Aggregator (or Aggregator Cluster), and Collectors. See Installation Requirements and see
Required image files below for details.
3 Obtain the IP for the Management Server

The IP for the Management Server can be obtained as follows:
● SaaS: Obtain the IP from Guardicore Support.
● On-Premises Deployment: Obtain the IP from the Network.

1.3.1 Required image files
Download the appropriate Image files from the Guardicore customer portal:
Installation Type Image file
Management Distributed Management Aggregation Deception

Server Nodes Server Server
On-Premises ✓ ✓ ✓
On-Premises with
✓ ✓ ✓ ✓
Distributed
Management
SaaS
✓
Note: For VMWare deployment, The ESX Collector component is installed using the same
OVA as the Aggregator (the Guardicore Aggregation Server OVA).

After downloading, provision VMs using the image files. For the On-Premises with Distributed
Management Cluster, see the table in the section above, Requirements for Distributed
Management Cluster, for the list of servers that you will need for the Management Cluster.
1.3.2 AIO- Computation Requirements
Component Requirements
Management Server For On-Premises Only.
For Distributed Management, see Requirements for Distributed

Management Cluster.
For SaaS: No requirements, the Management Server is in the cloud.
CPU 8 vCPUs
RAM On-Premises, AiO

32 GB.
Storage 530GB
Connectivity Interfaces to:

● (Optional) Guardicore network*
● Network to provide users with UI and API.
● Network for Email, SIEM and FW integrations.
● Outgoing communication to internet for enrichment services and
system health monitoring.
Static IP(s) should be assigned in the relevant network(s).
Number of required NICs depends on customer’s networking.
Aggregator
CPU 4 vCPUs

Memory RAM: 4GB

Storage: 30GB

● (Optional) Guardicore network*
● Connectivity to Agents (guest) network(s). Using NAT is supported.
● At least one Aggregator / Collector should be able to reach the
vSphere management network (vCenters).
Deception Server For On-Premises Only
For SaaS: No requirements, the Deception Server is in the Cloud.
CPU 8 vCPUs
Memory ● 32GB RAM

● 100GB storage
Connectivity The Deception Server should have a single interface in the Guardicore
network*, used for communication with the Management Server and ESX
Collectors.
A static IP should be assigned.
ESX Collector Only for VMWare deployment
CPU 2 vCPUs
Memory 2GB RAM

30GB storage

● SPAN port connection to each of the host's vSwitches to be

monitored. This interface(s) does not require an IP.
● (Optional) Guardicore network* assigned with a static IP.
● At least one Aggregator / Collector should be able to reach the
vSphere management network (vCenters). Assigned with a static IP.
SPAN or IP-Flow For resource and connectivity requirements- refer the specific install
Collectors guides for the components.
*Guardicore Network: Used for communication with the Management Server, Deception Server,
Collectors, and Aggregators.

1.3.3 Distributed Management Cluster- Computation

Requirements
Note: Requirements for Aggregators, Collectors, and Deception Server are as detailed in the
On-Premises Requirements Section above. To design a Distributed Management Cluster that is
customized for your system, consult with Guardicore Professional Services/Customer Success on
which nodes are needed and how many of each type. See the Scaling Architecture section for
further understanding of the required VMs for a clustered deployment.
Management Prerequisites
Component
Node
CPU 8 vCPUs
● 32 GB RAM
Memory ● 30GB storage capacity for root file system
● 500GB storage capacity under /storage mount
● Deploy the server in Thick Provisioning
Connectivity Interfaces to reach:

● (Optional) Guardicore network
● Network to provide system users with UI and API.
● Network for Email, SIEM and FW integrations.
● Outgoing communication to the internet for enrichment services
and system health monitoring.
Number of required NICs depends on the customer's networking.

Worker Node
CPU 8 vCPUs
● 32 GB RAM
Memory
● 30GB storage capacity for root file system
Connectivity Interface to:

● (Optional) Guardicore network, used for communication with
Control.
The number of required NICs depends on the customer's networking.
Elastic Node
CPU 8 vCPUs
Memory ● 32 GB RAM
● 1TB storage capacity under /storage mount

Control.
MongoDB Node
CPU 8 vCPUs

● 1TB storage capacity under /storage mount

Control.
RabbitMQ Node
CPU 8 vCPUs

Control.
InfluxDB Node
CPU 8 vCPUs

● 30 GB storage capacity for root file system
● 200 GB storage capacity under /storage mount

Control.

1.3.4 Connectivity Requirements Diagram
Connectivity Requirements Diagram
The above diagram indicates the connectivity requirements for a single Management Server
configuration. For a distributed Management cluster, there are more requirements for
communication within the cluster; contact Guardicore support for internal communication
requirements for the Management cluster.

2 Installation instructions- Centra

2.1 Vmware installation
Depending on the type of Installation, at this stage you can begin deploying Centra components.
For On-Premises and On-Premises with Distributed Management Cluster, the first component to
deploy is Management. For SaaS installations, Management is in the cloud and doesn’t require
installation.
This section includes subsections for both On-Premises Configuration, and Distributed
Management Cluster configuration.
Note: Obtain IPs for On-prem components: Management Server, Deception Server, Collector(s), and
Aggregator(s) prior to commencing the install process as these IP addresses will be used during the
installation process.
Note: Create a Read Only User on vCenter (Optional).

Configuring vCenter Orchestration enables loading VM inventory into Centra (machine names, status,
networks, MACs, etc), giving better context to assets on the Reveal map and across the whole system.
Creating a Read Only User in this step will enable you to configure vCenter Orchestration later in the
installation.
For instructions on establishing a read-only user on vCenter, see Creating a user in vCenter for read only
access.
Note: After initial deployment of the Centra management cluster, advise with the Professional Services
team for the latest “Service Pack” version, obtain the needed files and install the package according to
Appendix B.

2.1.1 On-Premises Configuration (AIO)
1. Make sure the Management server VM was provisioned using the appropriate OVA, and
that the compute specs and networking are set as required (see the section on Enabling
Optional Services below before starting) .
2. Turn on the Management Server VM and open the console.
3. Login with the following credentials:
User : admin
Password : GCAdmin123
Note:
● After the root user’s password is set in step 4 below, the àdmin` user will be disabled.
● After system boot, the installation wizard will wait for the docker service to be ready in
order to start. This may take up to 5 minutes, during which you might not be able to login
The Setup Utility is displayed:

4. Click OK to display the following:
5. Type a new root user password for the machine and click OK. The password should consist
of at least 6 characters and contain both upper and lowercase letters and numbers, but no
punctuation marks or other symbols. You will be asked to enter your password selection
twice.
6. Click OK; the following is displayed:
7. Click Yes to configure the network interfaces. The following is displayed:

8. Select Static and click OK to set the Guardicore Network interface manually as in the
following example:
A similar wizard will display for each connected interface. Repeat interface configuration for all
connected interfaces.
Note: Having more than two network interfaces for the management is not supported.

Note: Steps 9-10 will only appear if you have more than one network interface for the
Management server.
9. Select the interface matching the Guardicore Internal Network, used for connectivity with
other Guardicore Centra components:
10. Select the interface matching the External Network - used for users’ connectivity to UI /
REST API / SSH.
11. Define the IP addresses that should be allowed to connect to the Management Server over
SSH (port 22). To allow all, add 0.0.0.0/0

1. Configure default iptables Management policy (optional).
Note: Guardicore strongly recommends that you configure this now and click Yes:
Explanation: Select YES to reset the iptables INPUT chain config, unless you already set
any local rules manually before running the wizard, and Guardicore confirmed you don't
need to reset this INPUT chain. You may have set any other rules manually in case you have
more appliances running on this machine. If not, and the sole function of this machine is
running the GC appliance, you can safely click YES and have the automation define the
iptables for you.
Choosing YES will clear all rules in the INPUT chain. To skip, choose NO. This can be
configured after the completion of the wizard- on the machine itself.

12. Set a Guardicore Secure Communication Token_ID (password). This will be used by Centra
components to authenticate against the Management Server during installation.
Note: Use only alphanumeric characters for the Token_ID (password)
13. Set a password for the UI default admin user:
15. Click Yes to enable the Guardicore Reputation Service.
Note: this setting can later be changed from the UI.

The following is displayed:
16. You must click Yes to enable the Segmentation Policy Enforcement feature. Selecting No is
no longer supported. The following is displayed:
17. Type a name for the environment. The name will be used during the integration with
Guardicore’s health monitoring system and should be later coordinated with a Guardicore
representative.
Note: Selecting an environment name is optional. You can skip setting a name by leaving the text
empty.

19. Select AIO (All in One) installation. The following is displayed:
20. Type the Management IP in the Guardicore Internal Network and click OK:
21. Click Yes to continue or No to edit your configuration. After clicking Yes, the following is
displayed.

22. Click OK to start the installation. Installation execution can take up to 30 minutes:
After the installation is complete, you can log in into Centra’s UI using the user admin and the
password you chose.
Note: It is possible to replace the UI certificate with your own (customer) certificate. In order to
do it, create a support ticket. You will be emailed as soon as the request is received.

2.1.2 On-Premises Distributed Management Configuration
For efficiently installing Centra in a Distributed Management configuration, follow these steps:
A. Provision the Machines and Create an IP-plan
1. Make sure you have provisioned the required machines as detailed in the section
Requirements for Distributed Management Cluster.
2. Create an IP-plan so that each member of the cluster has an IP you can assign during the
B. Deploy VMs from OVAs and Configure Networking
The objective of this step is to provision all required VMs from *.OVA templates and connect the
VMs to the network, so all subsequent steps can be done remotely over SSH sessions.
1. Deploy the Management Control node from the OVA.
Expected OVA name: Guardicore_Management_Server_<version>.ova
2. Deploy each of the Management Distributed Nodes from the Distributed nodes OVA.
Expected OVA names:
Worker node: Guardicore_Managemenet_Node_U18_200gb.ova
RabbitMQ node: Guardicore_Managemenet_Node_U18_200gb.ova
InfluxDB node: Guardicore_Managemenet_Node_U18_200gb.ova
MongoDB node: Guardicore_Managemenet_Node_U18_1tb.ova

ElasticSearch node: Guardicore_Managemenet_Node_U18_1tb.ova
PostgreSQL node: Guardicore_Management_Node_U18_1tb.ova

Sizing of PG node is decided and configurable.
3. Turn on all the deployed Management Cluster VMs, and login with the following
credentials:
User : root
Password : GuardR00t111
4. Make sure the time on each node is correct and synched with the Control node. You can
achieve this either by manually setting the time on each node or by ticking the
“Synchronize guest time with host” box in the VM options of the machine, under Settings
(in the Vsphere Client). Failing to accomplish this stage on all nodes will result in a failed
installation.
5. On each machine, configure the network interfaces according to the deployment IP-plan.
Using “ifconfig -a”, identify which MAC address is assigned to each logical interface,
comparing those with vSphere settings to identify the interfaces that should be configured
according to the IP-plan.
Make sure the network interfaces are up and running by performing:
ifconfig eth0/1.. up
and confirm with ifconfig again.
6. Do the following to reconfigure Netplan:
a. Run the following command to disable Netplan’s SaaS config:
echo "network: {config: disabled}" >

/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
b. Remove the existing Netplan configuration:

rm /etc/netplan/*
c. Update the /etc/netplan/01-network-card.yaml configuration file for your network

using vi or nano editors. Here are some examples:
######################################################################################
######################################################################################
##########################
## Examples:
## Example 1 - Use DHCP
#network:
# ethernets:
# ens160:
# addresses: []
# dhcp4: true
# dhcp-identifier: mac
# version: 2
### Example 2 - Use a static IP address of 192.168.1.1 with a gateway of

192.168.1.254 and netmask of 255.255.255.0, also add 8.8.8.8 as the nameserver
network:
ethernets:
ens160:
addresses: [192.168.1.1/24]

gateway4: 192.168.1.254
dhcp4: no
nameservers:
addresses: [8.8.8.8]
version: 2
## Example 3 - On ens160 Use a static IP address of 192.168.1.1 with a gateway of

192.168.1.254 and netmask of 255.255.255.0, also add 8.8.8.8 as the nameserver, and
on ens192 use DHCP
#network:
# ethernets:
# ens160:
# addresses: [192.168.1.1/24]
# gateway4: 192.168.1.254
# dhcp4: no
# nameservers:
# addresses: [8.8.8.8]
# ens192:
# addresses: []
# dhcp4: true

# version: 2
###################################################################################
###################################################################################
Note - the nameservers configuration is optional. If multiple DNS servers are needed, separate
them with commas.
7. Restart the network interface for the change to take effect:

netplan try
8. Restart the VM using reboot.
9. Connect to each instance remotely using SSH. To do this, follow the instructions in the next
section (Preconfiguration of Management Nodes). After completion, you will be ready to
run the setup wizard from the Control.
C. Preconfigure the Management Cluster Nodes
In this step you configure hostnames for the Management cluster nodes, reset the root password,
and sync SSH keys from the Control. You will then be ready to run the setup wizard.
Configure Hostnames
On each of the Management cluster node instances (excluding the Control), configure a
meaningful hostname. A suggested naming scheme is provided here, although you may want to use
alternative hostnames that comply with the company policy instead.
● Worker node: gc-Worker-1
● RabbitMQ nodes: gc-rabbit-1, gc-rabbit-2
● InfluxDB node: gc-influx-1

● MongoDB nodes: gc-mongo-1, gc-mongo-2, gc-mongo-3
● ElasticSearch nodes: gc-elastic-1, gc-elastic-2, gc-elastic-3
Configure as following:
1. Run the following, replacing <HOSTNAME> with the new hostname:
hostnamectl set-hostname <HOSTNAME>
NOTE: If you get “Failed to create bus connection: No such file or directory” then simply
reboot, log back in, and then retry.
2. Edit /etc/cloud/cloud.cfg changing preserve_hostname from false to true
3. Edit the line containing the loopback IP address in the file /etc/hosts.
Replace
127.0.1.1 gc-management-node
with
127.0.1.1 <NEW_HOSTNAME>
4. Verify that the new hostname has been configured: hostnamectl

Note: to see the new hostname displayed in the prompt, reconnect to the node using
SSH.
Reset Root Password

Change the root password of each of the nodes using passwd
Sync SSH keys from the Control

1. Login to the Control server with the following credentials:
User : root
2. Allow passwordless SSH login from the Control node to all the other nodes, by running the
following command on the Control node for each node:
ssh-copy-id <Node IP>

D. Configure the Management Cluster

Configuring the Management Cluster requires the following:
● Run the Setup Wizard.
● Adjust the ElasticSearch Cluster Heap Size.
● Configure the RabbitMQ Redundancy Cluster.
● Configure the MongoDB HA Cluster.
Instructions for these procedures are provided below.
Run the Setup Wizard

On the Management Control:
1. Start the installation setup wizard by running the command
mgmt-setup
2. The Setup Utility appears:
Click OK and select a new root user password for the machine. You will be asked to enter your
password selection twice:

3. Click Yes to set the root password and disable the default “admin” user:
4. Click Yes to configure the network interfaces
5. Choose Static to set the Guardicore Network interface manually:
6. Configure the interface settings:

7. A similar wizard will display per each connected interface. Repeat interface configuration
for all connected interfaces.
Note - more than two network interfaces configuration is not supported.
Note: Default gateway should be set Only on one interface, usually on the external interface!!!
other Guardicore Centra components.
9. Select the interface matching the External Network - used for users connectivity to UI /
REST API / SSH:

SSH (port 22). To allow all, add 0.0.0.0/0:
iptables for you.

12. Set a Guardicore Secure Communication password. This password should be a secret
password, used by Centra components to authenticate against the Management Server
during installation. Please use only alphanumeric characters for passwords.
13. Set a password for the UI default admin user.
14. Click Yes to enable the Guardicore Reputation Service. Note that this setting can be later
changed from UI.

15. Entering the environment name is optional. You can skip it by leaving the text empty. If
entered, the name is used during system health monitoring integration, and should later be
communicated to Guardicore representative.
16. Select Cluster (Distributed Management) installation.
17. Type the Management IP in the Guardicore Internal Network.

18. Enter Management Worker nodes IP addresses. Make sure to also include the
management Control IP in the Workers list.
Note: In the next steps (19-22), you configure the IP of each dedicated external node. The
controller node’s IP should only be included in the list if the controller node is planned to
take one of these roles.
19. Enter MongoDB node IP address. If the deployment requires more than one MongoDB
node, enter only the IP of the 1st MongoDB node, and configure a RabbitMQ Redundancy
Cluster or a MongoDB HA Cluster after this step is complete.
20. Enter ElasticSearch node/nodes IP address/es.

21. Enter InfluxDB node/nodes IP address/es. Note - in case the influxDB node will run on the
Management Control node, specify the Management Control’s IP. Leaving this screen
empty and not configured will break the install process.
22. Enter RabbitMQ node IP address. If the deployment requires more than one RabbitMQ
node, enter only the IP of the 1st RabbitMQ node, and see Configuring RabbitMQ
Redundancy Cluster for adding an additional node after this step is complete.
Enter Postgress Daily Flows node IP address. In case there is no external node for the Postgress
service- fill in the Management Control node’s IP address. Leaving this screen empty and not

configured will break the install process.
23. Click Yes to continue.
24. Click OK to start the installation (ignore the “Setup completed” message). Installation
execution can take up to 60 minutes.

Note:
In case the flow is interrupted with the following error:
Upgrade failed on state “START_CLUSTER_INFRA”, check
“/var/log/guardicore/upgrade_service.log”
Wait 5 min and run:

gc-patch-resume
27. Set Management configuration to utilize all Elastic nodes:
gc-cluster-cli service-scale --service_name elasticsearch

--instances <NUMBER OF ELASTIC SEARCH NODES>
28. Validate the UI is accessible by connecting to Centra UI by browsing to the Control node’s
external interface IP over port 443. Note: There is an option to replace the UI certificate by your
own (customer) certificate. Click here to create a support ticket. You will be emailed as soon as we
receive your request.
29. Validate full Management cluster health by running on the Control:
gc-cluster-cli health
Adjust ElasticSearch cluster heap size

For ElasticSearch clusters of size 3 and higher, with each node having 32GB, the jvm heap size
allocation should be increased from 8BG (a default value for all-on-one Management) to 20GB.
On the Management Control node:
1. Edit the file /etc/guardicore/guardicore_setup.conf
Locate the configuration "override_es_heap_size": 8, and change it's value
to 20.
2. Edit the file /etc/guardicore/cluster/resources.json

Locate elasticsearch and change “memory”: 20000 to “memory”: 28000

3. For the change to take effect:
gc-cluster-cli infra-service-restart --infra_name cluster-manager
gc-cluster-cli service-restart --service_name elasticsearch
Configure RabbitMQ Redundancy Cluster

Register a standby RabbitMQ node used for redundancy. In this configuration, in case the primary
RabbitMQ node fails, the cluster manager (executed on the Control) injects RabbitMQ into the
standby node which automatically replaces the primary one. The median time before a new
RabbitMQ will replace the primary one should not typically exceed 3 minutes.
Setup
Execute the following command on Control to configure a standby RabbitMQ node:
gc-cluster-cli add_node --node_type rabbitmq --node_address
<Standby_RabbitMQ_IP>
Validation
This command should perform the following actions:
● Adds the IP address of standby RabbitMQ node to

/etc/guardicore/guardicore_setup.conf on the Management Control

/etc/guardicore/hosts on the Management Control server
● Adds the true indicator to the rabbitmq line of the file on the second RabbitMQ host:
/etc/guardicore/cluster/attributes
Note: Be aware that in case of a failover process, existing unprocessed messages in the queue
will be lost.

Configure MongoDB HA Cluster

By default, MongoDB is installed in Guardicore as a stand-alone node. When HA is necessary,
MongoDB can be extended to a cluster of 3 nodes in HA replica-set configuration. A replica-set
refers to a group of MongoDB servers that operate as a cluster and replicate data. The replica-set
meets both redundancy and failover requirements. Each node in the replica set has a role, in this
case, either Primary or Secondary:
The primary MongoDB server is the "Control" node. It is the only MongoDB that is allowed to write
data and all writes go through this MongoDB node. Whenever a replica set is installed, an
election process is held to elect the primary MongoDB server. This will also happen if the current
primary dies.
The secondary server replicates data from the primary node. Secondary servers are not allowed to
write. A secondary server can become a primary node via an election process. (assuming it's
configuration allows it).
When there is a successful Failover (i.e. when the primary node fails and cannot communicate with
the rest of the cluster secondary nodes for more then 10 sec, by default), a new primary node is
elected.
Setting up the MongoDB replica-set for Guardicore requires four stages:

Stage 1: Check prerequisites.
Stage 2. Initialize the Replica-set.
Stage 3: Add members to the Replica-set.
Stage 4: Start the Replica-set cluster.
The four stages and their steps are provided below:
Stage 1: Check Prerequisites
1. Make sure that all MongoDB replica set nodes are available via ssh and will not require
a password. You can use the following command to do this:
ssh-copy-id <node_address>
2. Make sure that the iptables will allow the 27017 (TCP) traffic between these nodes.
Stage 2: Initialize the Replica Set
To initialize the MongoDB replica set:

1. On the Control management node run the following command:
gc-mongodb-cluster-cli init
This will create a replica set with a single MongoDB node.
Note: When running init, the app group is stopped to avoid CPU spikes due to the
interruption of MongoDB service.
Note: If the initialization of the MongoDB replica set fails following the previous command,
use the next walkaround:
export IMAGE_TAG=$(python -OO
/var/lib/guardicore/management/docker_deploy/scripts/cluster/startup
/helpers/get_image_tag.pyo -i gc-service)

export REGISTRY_IP=$(python -OO

/var/lib/guardicore/management/docker_deploy/scripts/registry/get_re
gistry_ip.pyo)
docker run --net=host -it --rm --entrypoint bash
"$REGISTRY_IP":5000/gc-service:"$IMAGE_TAG" -c "mongo <mongo URI
printed by the script>"
# From mongodb shell
rs.initiate({"_id": "guardicore_replica_set", "members": [{"_id": 0,
"host": "<host mongo internal ip>"}]})
# You should see { "ok" : 1 }
exit
Retry the failed command and continue with the procedure.
2. Verify the MongoDB replica set was successfully initialized using the following
command:
gc-mongodb-cluster-cli health
The result should be similar to the following
At this point there should be a single server with status Primary whose health is ok.
Stage 3: Add Members to the Replica Set
Once the replica-set has been initialized, it is ready to accept new members.
1. To add a node to the replica set & the Management cluster use the following:

gc-mongodb-cluster-cli add --node_address <node_address> --add_to_cluster
The --add_to_cluster will make sure to first add the new machine as a management cluster
node. This will do what gc-cluster-cli add_node does, just specifically for the mongodb node
type. Once the node is part of the management cluster it will be added as a member in the
initialized MongoDB replica set.
IMPORTANT:
● There is NO need to add the MongoDB replica set nodes via gc-cluster-cli.
● If the nodes were already added via gc-cluster-cli, skip passing the
--add_to_cluster flag when running the above.
2. To verify the new node successfully joined the existing MongoDB replica use the
following command:
The result should be similar to the following:
■ At this point there should be a single server with status Primary whose health is ok.
■ In addition, you should have a single server with status Secondary whose health is ok.
(above example has more nodes).
This process can be repeated for each node you want to add to the replica set.
■ It is critical for high availability to have a replica set with at least 3 nodes.
■ The number of nodes must be odd for the primary election to work (there is an arbiter
option which is not yet supported).

Stage 4: Start the Cluster
Once the process of forming the MongoDB replica set is complete and all desired nodes are a part
of the replica set issue the following command:
gc-cluster-cli cluster-restart

2.1.3 Deception Server deployment

(for on-premises configurations only)
1. Turn on the Deception Server VM and open the console.
User: admin
Password: GCAdmin123
Note: After the root user’s password is set in step 4 below, the àdmin` user will be disabled.
The Guardicore Setup Wizard is displayed:
3. Click OK to go through the wizard steps. The following is displayed:
4. Type a new root user password for the machine and click OK. The following is displayed:

5. Click OK to edit the local network interfaces. The following is displayed:
6. Choose Static to set the Guardicore Network interface manually. The following appears:

7. If there is more than one network interface for the Deception server, The following prompt
will appear:
8. Select the interface which is considered the “Attacks Interface” (The interface from which
the Deception server is receiving attack events) and click OK.
9. Enter the IP address of the Management Server in the Guardicore network and click OK.
10. In the Tunnel port screen accept the default 443 port by clicking OK. The following is
displayed:

11. Enter the Secure Communications password as set in the installation of the Management
Server and click OK. The following appears:
12. Define the IP addresses that should be allowed to connect to the Deception Server over

14. Click Yes to continue or No to edit your configuration:

2.1.4 Collectors deployment

You can choose to deploy the following types of collectors:
● ESX collectors
● SPAN collectors
● IP Flow collectors
Collectors and Aggregators are deployed from the same OVA and are represented as components
in the same installation screens. Instructions for deployment of each type of collector are provided
in the following subsections.
Note: For ESX and SPAN collectors, a properly configured and working vSphere Orchestration is
a prerequisite for the Collector to function fully. Without a configured vSphere Orchestration,
the Collector will provide Reveal functionality, but will not provide Deception functionality.

2.1.4.1 ESX Collectors deployment
There are two possible modes of deployment for ESX Collectors:
● Manual deployment and configuration of each Collector separately.
● Automatic deployment of multiple Collectors using the Collector Deployment Tool.
To deploy a small number of ESX Collectors, manual deployment is recommended. To deploy a

larger number of ESX Collectors, use the Collector Deployment Tool (GuarDeployer).
Prerequisites:
Note: Prior to Collector installation, a virtual SPAN port group should be created on each of the
host's vSwitches that are to be monitored. See Appendix B: Create a SPAN Network Port
instructions.
Manual Deployment of ESX Collectors
1. Turn on the Collector VM and open the console.

User : admin
Note: After the root user’s password is set on step 4, the àdmin` user will be disabled.
3. Click OK to go through the wizard steps:

4. Type a new root user password for the machine:
5. Click OK.
6. In Component Type, select Esx Collector
7. Select the SPAN interfaces (multiple vSwitches on the same host can be monitored with a
single ESX Collector):

8. Click OK to configure the network interface:
11. Enter the IP address of the Management Server in the Guardicore network:

Server:
13. In Advanced Settings, configure any setting you wish to change/use. Otherwise select
Continue.
Advanced Setting Configuration

If you clicked Advanced Settings the following screen appears:

a. Under Hostname, write the hostname you wish to use for the Collector:
b. If you are using an external PKI with a SCEP endpoint, you can use the collector as
a SCEP proxy. Enter the SCEP server address to enable this configuration:
c. Under Cluster Roles, select the roles you wish the Collector to take:
ClusterExporterServicesHost - the Collector will connect to a SIEM to export

syslog.

ClusterOrchestrationServicesHost - the Collector will connect to orchestration

services and retrieve inventory and configuration data related to assets, network
topology and location information.
ClusterZooKeeper - the Collector will be a member of the ZooKeeper quorum. If

none is selected in this cluster, the ZooKeeper quorum will be randomly elected by
the members of the cluster.
InventoryAPIOrchestEnable - Inventory API orchestration is enabled.
When you are finished with Advanced Configuration, click OK to continue.
14. Define the IP addresses that should be allowed to connect to the ESX Collector over SSH
(port 22). To allow all, add 0.0.0.0/0

16. Choose the Cluster ID for the collector. Note: Starting v36, when installing a collector in
an environment without Legacy Deception feature in the Aggregator- the cluster ID for
the collector must be different from the Aggregator’s cluster ID. Orchestration then must
be set to this cluster.
17. If DRS is enabled on the VMWare cluster, the Collector VM should be fixed to its host. See
full instructions on Appendix B.
Automatic Deployment of ESX Collectors using the Collector Deployment Tool
The Collector Deployment tool (GuarDeployer) allows mass deployment of ESX Collectors on
VMware environments. The tool works with a single Datacenter at a time but can run multiple
times for coverage.
The deployment is done in 3 steps:
1. Tool setup
2. Configuration adjustments using a YAML file
3. Deployment
Prerequisites:
1. Installed Management Server

2. Aggregator \ Collector \ General Server OVA is uploaded to the datastore, and

converted to a template named GC-TEMPLATE
3. vCenter root \ admin credentials
Step 1: Setting up the tool
This step sets up the tool and helps the user create a full configuration which could be executed at
a later stage.
1. Deploy a machine from the template GC-TEMPLATE. This machine should be connected to
networks that allow connectivity to:
o vCenter (over outgoing vCenter port, usually 443)
o user's endpoint (over incoming port 443)
Note: No connectivity to the Guardicore Management server is required.
2. Open the new tool’s console.
User: admin
Password: admin
4. In the Component Type screen choose GuarDeployer.
Step 2: Adjusting the tool’s configuration to the user’s needs
To adjust the configuration, go to https://<guardeployer_ip>/current_yaml. The current YAML file

includes the suggested configuration based on step 1 and the vCenter properties.
Step 3: Deployment
After filling in the fields, click Submit and Run to start the deployment.

The new components will be deployed from the GC-TEMPLATE and you'll start to see new
machines deployed and reconfigured in the vSphere Tasks screen.

2.1.4.2 SPAN Collectors Deployment

SPAN collectors must be installed manually. Follow these instructions:
The SPAN Collector is used to support the scenario of protected physical assets monitored by a
SPAN on a physical switch / TAP / Network Packet Broker.
The SPAN Collector reads L2 row traffic from an input interface, which supports Centra’s Reveal
(visibility) feature. In addition, having an inject interface, it can support Centra’s Deception
functionality.
To scope the assets monitored by the SPAN Collector, protected_cidr configuration should be set
with the list of relevant subnets / IPs.
Requirements
● 4GB RAM
● 4 vCPUs
● 30GB storage
Connectivity
The SPAN Collector should have the following interfaces:
● SPAN port connection to the host's vSwitch connected to a physical port connected to a
physical switch / NPB / TAP where the physical servers that are to be monitored are
connected. This interface does not require an IP.
● If Deception functionality is to be activated, the SPAN Collector also requires an inject

interface to the host's vSwitch connected to a physical port connected to a physical switch
by a Trunk link. This interface does not require an IP.
● An interface in the GuardiCore network, used for communication with the Management
and the Deception Server (if Deception is activated). This interface should be assigned with
a static IP.

SPAN Collector Installation Procedure

1. Login to the collector VM as:
User: admin
2. Select SPAN Collector and click OK:

3. Select the network interfaces to use as “Span Interfaces”:
4. Select a network interface as the “Output Interface” for the Span interface:
5. Enter the Management IP address:
6. Enter the Secure Communication Password:
7. Enter SSH Access:

8. In Advanced Settings, configure any setting you wish to change/use and click OK.
Otherwise, select Continue:
9. Under hostname, write the hostname you wish to use for the Aggregator:

10. Under SCEP, configure the URL for SCEP (dbPKI):
11. Select the roles you wish to assign to the Collector:
Role Description
ClusterExporterServicesHost Aggregator will connect to a SIEM to export syslog.

ClusterOrchestrationServicesHost Aggregator will connect to orchestration services

and retrieve inventory and configuration data
related to assets, network topology, and location
information.
ClusterZooKeeper Aggregator will be a member of the ZooKeeper

quorum. If none is selected in this cluster, the
ZooKeeper quorum will be randomly elected from
LegacyDeception Select this option to support deception for agents

from version prior to v36. Unmarking this option will
cause old agents not to redirect traffic to the
deception server, letting the Aggregator handle ~
250 agents.
Marking this option will turn on support for
redirecting deception traffic for old agents (prior to
v36), but will limit the number of agents handled to ~
100.
Note: In case there is a need to change the
configuration and add a support for this feature, run
the setup of the aggregator again (aggr-setup) and
mark the feature as enabled under Administration >
Aggregator > Features > Legacy Deception.
Also- all aggregators in the cluster must be of the
same type, and- once changed, the aggregator will
not support deception for the other type of agents.

13. Click Yes to continue or No to edit your configuration.
14. Select a Cluster for the Collector:
Setup will finish, displaying the following screen:
15. In the Centra Management UI, click on Administration/Components/Collectors, select the

Collector, and then select More/ Override Configuration:

16. On the Override Configuration dialog box, click Show Advanced Options and In the list of
Advanced Options, select port mirror cloud driver. In the right pane, click protected-cidr:
The Protected-Cidr screen appears:

13. In the Protected-Cidr screen, add the IPs of the subnets which should be covered by the SPAN
Collector and click OK.

2.1.4.3 IP Flow Collector Deployment
Deployment of an IP Flow Collector is required in case there is a need to ingest traffic from the
following formats:
● Collecting visibility data via a Big-IP F5 integration.

○ Make sure to configure the collector with the correct settings, as described in
bullet 11 below.
● Ingesting flows from switches from the following formats.
○ IPFIX flows directly from a switch.
○ Netflow V5
○ Netflow V9
○ sFlow V5
Requirements
● 4GB RAM
● 4 vCPUs
● 30GB storage
● 4 mitigation workers
Connectivity
The IP Flow Collector should have the following interfaces:
● (Optional) Guardicore network* assigned with a static IP.
● Connectivity with switches / F-5 for ingesting data flow.
To deploy an IP Flow collector:

1. Follow steps 1 - 5 in Manual Deployment of ESX Collectors above.
2. For Component Type, select IP Flow Collector and click OK.

3. Select desired flow formats to be ingested from the customer’s switches.

The flows format and port are to be configured for export on the switch.
Note: More than one format can be selected.
IPFIX Notes:
● If you intend to ingest IPFIX data either from an F-5 integration or directly from the
switches, mark the IPFIX option. It is not supported to ingest IPFIX data both from
switches and via F-5 integration at the same time.
● If IPFIX data is going to be ingested directly from switches and not via F-5
integration, set the following configuration, on the Collector VM, after the
completion of the install wizard:
○ In /etc/guardicore/mitigation.conf

○ Set:
■ [ipflow-machine-tracker]
■ F5-support = False
○ Restart the flow collector service, either via UI or CLI
Note: In the current version, the advanced configuration of the collector

for “Support IPFIX visibility for F5 switches” is not relevant and the
configuration still has to be made through the CLI as described before.
○ If there is a time skew between the switch time and the collector server
time, which may be the case when the time is not synchronized with a time
server or there is time zone difference etc., set the following configuration,
with the time offset in minutes:
■ [ipflow-machine-tracker]
■ Time-offset = <time in minutes>
○ Restart the flow collector service, either via UI or CLI

4. Select port for each flow format (one for each format):
5. Choose OK to configure the interface on the machine:

Server:

10. Click OK.
11. In case the collector is going to be used for F-5 integration, follow this section. It is
relevant if you intend to configure a webhook for a collector in the Centra F5
orchestration. If you intend to configure a webhook, do the following for the relevant
collector
a. Under Advanced Settings, select Set Aggregator Cluster Roles:
b. Click OK and continue to the Cluster Roles dialog box:
c. Select ClusterOrchestrationServiceHost and click OK.


2.1.4.4 Collector Appendices

2.1.4.4.1 Collector Appendix A: How to create DRS rules to fix ESX Collectors to hosts
1. Using Vsphere Client
2. Using Vsphere Web Client
Note: Configuring DRS rules for ESX Collectors is required only if vSphere DRS is in use
How to create DRS rules to fix ESX Collectors to hosts using the vSphere Client
For each deployed Collector, follow the instructions:

1. Right click Cluster > Edit Settings.
2. Click Rules > Add.

3. Click the DRS Groups Manager tab.
4. Click Add under Host DRS Groups to create a new Host DRS Group. Add the host of the
Collector. Name it indicatively (recommended - “guardicore-host-group-HOSTNAME”).

5. Click Add under Virtual Machine DRS Groups to create a Virtual Machine DRS Group. Add
the Collector VM. Name it indicatively (recommended -
“guardicore-vm-group-for-COLLECTOR-X”).
6. Click the Rule tab, give the new rule an indicative name (recommended -
“guardicore-rule-for-HOSTNAME”).
7. From the Type drop-down menu, click Virtual Machines to Hosts.

8. Under Cluster Vm Group select the newly created VM group.

9. Select Must run on hosts in group.
10. Under Cluster Host Group select the newly created Cluster Host Group and click OK.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1
005508)
How to create DRS rules to fix ESX Collectors to hosts using the vSphere Web Client
For each deployed Collector, follow the instructions:

1. Under Hosts and Clusters, select the Cluster and click Manage > Settings > DRS Groups.

2. Click Add and create a new Host DRS Group. Add the ESX host of the Collector. Name it
indicatively (recommended - “guardicore-host-group-HOSTNAME”).
3. Click Add and create a new VM DRS Group. Add the Collector VM. Name it indicatively
(recommended - “guardicore-vm-group-for-COLLECTOR-X”).

4. Click the Rule tab, give the new rule an indicative name (recommended -
“guardicore-rule-for-HOSTNAME”).
5. From the Type drop-down menu, click Virtual Machines to Hosts.
6. Under Vm Group, select the newly created VM group.
7. Select Must run on hosts in group.
8. Under Host Group, select the newly created Cluster Host Group and click OK.

2.1.4.4.2 Collector Appendix B: Create a SPAN Network port

1. Using Vsphere Client
2. Using Vsphere Web Client
3. On N1KV switch
Create a SPAN Network port for the ESX Collector using Vsphere Client
Create a SPAN on a standard vSwitch

For each ESX host do the following:
1. Open the host configuration tab, go to the Networking > Add Networking.
2. Create a new network on each vSwitch with the name GC-SPAN and set its vlan ID to All (4095).
(Tip: If there are multiple switches on the host, add the switch name to avoid name conflicts).

3. Go to the CG-SPAN Properties and under the Security tab set all the policy exceptions to
“Accept”
Create a span on a dvSwitch

1. Open the Networking tab, select the dvswitch, and create a Distributed Port Group. Set the
name to “GC-SPAN”, VLAN type to VLAN Trunking, and the trunk range to “0-4094”.

2. Go to the network properties and under the Security tab set all the policy exceptions to Accept.

Create a SPAN Network for the ESX Collector through Vsphere Web Client
Create a span on a standard vswitch
For each ESX host do the following:
1. On the vsphere web client, under Hosts and clusters view, select the ESX host and go to the
Networking > Add host networking
2. Create a new Virtual machine port group named GC-SPAN on each vSwitch, and set its vlan ID
to All (4095).
Tip: If there are multiple switches on the host, add the switch name to avoid name conflicts.

3. Select each newly created portgroup, and click Edit Settings. Under the Security tab set all the
policy exceptions to “Accept”.

Create a span on a dvSwitch
1. In the vSphere web client, under Networking tab, select the dvSwitch and create a new
Distributed Port Group. Set the name to “GC-SPAN”, VLAN type to VLAN Trunking, and the trunk
range to “0-4094”.

2. Select each newly created dvPortgroup, and click Edit Settings. Under the Security tab set
all the policy exceptions to “Accept”.

Create a SPAN port on n1kv
In n1kv installation, it is required to create two interfaces:

● Span interface - mirroring specific VLAN traffic
● Inject interface - interface which is used to inject traffic back to the network
To create span session in n1kv switch run the following commands on the n1kv switch console:
1. Create port profile that will be used for the mirrored traffic (the span “destination”)
configure terminal
port-profile type vethernet gc-span
switchport mode trunk
switchport trunk allowed vlan all
vmware port-group
no shutdown
state enabled
end

2. Set up a monitor session; it is required to define which vlan IDs are mirrored. If you reach the
limit (32 vlan per monitor session) you may need to set more than one monitor session.
configure t
monitor session 1
# Here you should specify the vlans of the port profile you use in your
network.
# In this example, we used vlan 1,2 .. 32
source vlan 1-32 both
destination port-profile gc-span
no shutdown
end
3. Create another port profile that will be used for injecting packets back into the network
configure terminal
port-profile type vethernet gc-span-inject
switchport mode trunk
switchport trunk allowed vlan all
vmware port-group
no shutdown
state enabled
end
4. Save the configuration so it would persist boot.
copy running-config startup-config


2.1.5 Aggregator(s) deployment
Deploying the Aggregators consists of two phases:
1. Configure the Aggregator’s FQDN
2. Deploy the Aggregators
Configuring an FQDN for the Aggregator has the following benefits:
● It makes it easier to achieve Aggregator HA - once one of the Aggregators is unavailable,

the Agents that were connected to it will re-query the DNS and reconnect to another
Aggregator.
● It is sometimes necessary to add additional Aggregators to the cluster (to support

expansion, etc). When Agents are installed against FQDN, adding a new Aggregator does
not require any configuration change on the Agents’ side - just add the Aggregator’s IP to
the DNS record.
Create FQDN(s) Record

Register a DNS A-record that includes an entry for each Aggregator in the cluster. This would
result in the following DNS results:
[root@localhost ~]# nslookup aggr.cus-xxxx.cloud.guardicore.com

Name: aggregator1.domain.com
Address: 35.193.234.123
Address: 35.183.204.118
In case an alternative solution such as GSLB is used, create the FQDN alias record in the GSLB.

Note: If the Aggregator was installed using the wizard prior to configuration of the FQDN, it is
possible to add the FQDN of the Aggregator’s cluster after the installation process. Refer to the
guide for configuring the Aggregator FQDN on an installed Aggregator.
Deploy Aggregators
3. In case a “Mega Aggregator” is needed, make sure the VM is provisioned with 32GB of
RAM and 12 vCPUs.
If not, stop the VM and change the resources consumption via “Edit settings”.
The Mega-aggregator is used to handle ~ 2000 Agents, with deception disabled. Please
note this when assigning responsibilities to the Aggregator in the installation wizard.
4. Turn on the Aggregator VM and open the console.
User: admin
Note: After the root user’s password is set in step 4, the àdmin` user will be disabled.
The following screen appears:
6. Click OK to go through the wizard steps.
7. Select a new root user password for the machine:

8. In Component Type, select Agents Aggregator:
9. Select the features you want the Aggregator to activate on its associated Agents:

Reveal Agents Server Basic Agent visibility functionality - should always be

selected.
Deception Agents Server Select this option to turn on deception capabilities for Agents
on guest servers that are not protected by ESX Collectors.
NOTE: Only select this option if you do not have a Deception

Server already, as this adds stress to the Aggregator and will
restrict its operation.
NOTE: If provisioning a “Mega Aggregator”, make sure this
option is marked OFF.
Enforcement Agents Server Select this option only if you want to turn on policy
enforcement capabilities.
Detection Agent Server Select this option to enable file integrity monitoring (FIM)
capabilities.
Agents Load Balancer Select this option to allow distribution of the Agent load to
other Aggregators in the cluster.
Legacy Deception Select this option to support deception for agents from
version prior to v36. Unmarking this option will cause old
agents not to redirect traffic to the deception server, letting
the Aggregator handle ~ 250 agents.
Marking this option will turn on support for redirecting
deception traffic for old agents (prior to v36), but will limit
the number of agents handled to ~ 100.
Note: In case there is a need to change the configuration and
add a support for this feature, run the setup of the aggregator
again (aggr-setup) and mark the feature as enabled under
Administration > Aggregator > Features > Legacy Deception.

Also- all aggregators in the cluster must be of the same type,

and- once changed, the aggregator will not support deception
for the other type of agents.
10. Click OK to configure the network interfaces:
11. Choose Static to set the Guardicore Network and the Agent facing interfaces manually.
A Static IP should be reserved in the customer’s network.

13. A similar wizard will be shown per each connected interface. Repeat interface
configuration until all connected interfaces are set.
Server:

16. Define the IP addresses that should be allowed to connect to the Aggregator over SSH

20. Select the roles you wish to assign to the Aggregator:
Role Description

information.


LegacyDeception Currently, error. Will be changed and updated to not

include this prompt.
21. Provide a list of FQDN addresses for the Aggregator:
22. If the Aggregator has a NAT facing the Agents, enter its IP address here:

25. At some point during the installation, the Cluster ID box appears:
26. Choose the Cluster ID for the Aggregator. If you do not have multiple
Collectors/Aggregator clusters, choose ‘default’.
NOTE: The design of how Collectors/Aggregators are assigned to clusters should be done
in consultation with Guardicore Professional Services/Customer Success.
Mega Aggregators
If the Aggregator is a “Mega Aggregator”, perform the following steps:
a. Log in to the Aggregator via CLI with the root user.
b. Edit /etc/guardicore/aggregator.conf by adding :
[enforcement_worker]
max_worker_number = 6

at the end.
c. Restart the Enforcement service:

monicore-ctrl restart gc-enforcement
d. Restart the Cluster manager service:
monicore-ctrl restart gc-cluster-mgr
e. Verify that the workers have been spun up properly – 12 mitigation workers, 6
enforcement workers:
ps -ef | grep mitigation - verify 12 worker entities.
ps -ef | grep enforcement - verify 6 worker entities.
f. If the workers have not been properly spun up, repeat Enforcement service restart
and validate that worker instances have been spun up successfully.
Log into the UI, verify in management → aggregator → override configuration →

“Max number of enforcement workers” is set to 6.

2.2 AWS Centra installation
About this Section

This section provides detailed instructions on how to install and deploy Centra in the following
configurations:
● AWS based Management server.

● AWS based Aggregators, communicating with a Management server, either on AWS or in a
different infrastructure.
This section includes the computing resource requirements for a successful installation,
instructions for preparing for the installation and required networking for the deployment.
The following install guide for AWS deployment is for an AIO management application.
Note: After initial deployment of the Centra management cluster, advise with the Professional Services
team for the latest “Service Pack” version, obtain the needed files and install the package according to
Appendix B.

2.2.1 AWS Configuration and Preconditions
Verify:
1. Administrative access to the AWS account.
2. Amazon Machine Image (AMI) of the Management and Aggregator components are shared
by GuardiCore with the customer’s AWS account/s, in appropriate regions/s.
3. For setting up a VPC, configuring subnets and other AWS configurations needed for the
success of this process- refer to this chapter. Please walk through every step in this chapter
to make sure connectivity is configured correctly.
4. Our AWS components’ appliance requires root user which can be reached in two ways:
a. SSH with root user and password to the aggregator. In this case please contact
Guardicore to receive the AMI’s root password.
b. SSH with ubuntu user and key, and switch to sudo after login. Ubuntu does have
sudo permissions. This option currently does not work.

1. Creating a VPC (an isolated portion of the cloud for AWS objects):
a. Push Services > VPC > Your VPCs > Create VPC
b. Add a name to the VPC
c. Add the CIDR you want your isolated environment to be in (i.e. 192.168.0.0/16).
You will later create subnets within this VPC in order to create different private
networks.
d. Add tags
e. Create VPC

2. Creating a Subnet within the VPC (similar to a VLAN):

a. Add a name to the Subnet
b. Add the VPC you want the subnet in
c. Add the IPv4 CIDR that you want your subnet to have (i.e. 192.168.1.0/24)

d. Create the subnet.
3. Creating Internet Gateway

a. Left menu- Internet Gateways
b. Create Internet Gateway
c. Pick the created gateway > Actions > Attach to VPC
d. Pick your VPC (a VPC without an Internet Gateway will be selectable).
e. Attach.

4. Creating Security Groups

a. Left menu > Security > Security groups
b. Name security group
c. Create inbound rules for the security group. Best practice here is:
i. Create a rule to allow SSH into the network from your known IP address.

ii. Create a rule that allows internal traffic- TCP in the same CIDR block as
your subnet.
d. Results should look like the following screenshot:
5. Create a Key-Pair to access your instances

a. Services > EC2
b. Left panel > Key Pairs > Create Key Pair
c. After downloading the .pem file, keep it in a secure place.
d. Will be used to connect to the machines created.
6. Edit Route Tables
a. Left menu > Route Tables > Pick the correct one (with the correct VPC) > Routes >
Edit routes
b. Add 0.0.0.0/0 - let’s instances communicate freely outside from the VPC > in
Target- add you Internet Gateway.

c. Add internal network’s CIDR block to enable internal communication.

2.2.2 Management Server deployment- AIO
Step 1 - Launch an EC2 instance for the Management server
A. Log in to your AWS web console and select the destination region for the Management
deployment.
B. Select Compute → EC2 to view your EC2 instances dashboard.
C. Launch a new instance:

a. Choose AMI. Select “My AMIs – AMIs shared with me” and locate the AMI shared by
Guardicore. You can find it by searching “Guardicore” or by using the AMI-ID (all your AMIs
are listed in EC2 Dashboard → Images → AMIs → Private)
b. Choose Instance Type. Select instance type, with EBS volume.
i. Standard requirement for a Management server is 16CPU, 32GB RAM. Meaning

for v36 control node we would take the m5.2xlarge EBS only instance (with 8CPU
and 32GB which are the recommended spec for an AWS management server).
c. Configure Instance Details. Mandatory fields are:
i. Network: choose the VPC of which will be used to communicate with the GC
components, usually known as GC-net Subnet: choose the subnet within the VPC
within the management server that will communicate with other components.
ii. Auto-assign Public IP:
i. If there is a need for the management to be reached from the outside

network (i.e Aggregators are outside of AWS) choose enable.

ii. If you want to access the Management from outside of your network-
Choose enable.
iii. Otherwise- if all the communication is conducted inside the VPC- choose
disable. You can also assign a public IP later on during the process.
iii. Under Network Interfaces, a single interface should be connected, configured with
a single IP (which can be Auto-assigned).
This is your GC-net. Either assign an IP for the management instance or click auto-
assign.
d. Add storage. The required storage parameters are 40 for the root partition and 500 for the
storage partition.

e. Add tags. Add a Name (example value: GC_Management_X). Additional tags can be added
according to customers conventions.
f. Attach Security Groups. (see appendix 4 for details) The SG should allow the following:
i. Inbound: All TCP and ports from my IP (can be adjusted later on for SSH etc.
ii. Inbound: All communication within the subnet.
iii. Outbound: By default, AWS SG allows any outbound communication. To validate

this, check the outbound configuration of the SG (from EC2 dashboard, Network &
Security → Security Groups).
g. Review the settings and launch the instance. To allow the connection to the instance, you
will be requested to choose an existing key-pair in the account or to create a new key-pair.
Refer to appendix for details on creating Key Pair.
Step 2 - *Optional* Generate an Elastic IP and associate it with the

Management
A. If an instance is not assigned with public IP yet- Create a new Elastic IP from Network &
Security → Elastic IPs (“Allocate a New Address”).
B. Right click on the address and associate it with the Aggregator instance.

Step 3 - Connect to the Management and validate connectivity

A. Connect to the Public IP of the Management via SSH, using the key-pair and user ubuntu.
a. You will need to run chmod 400 <key-pair.pem> before connecting.
b. If your key.pem resides under mnt/c/usr...- > applying chmod 400 will not change
the permissions as expected.
In order to change the permissions, move your key file to home directory (in root)
and apply the changes there, otherwise you will get a
Permissions 0555 for key.pem are too open
message.
c. Go to Instances → Instances, select the Aggregator, right click and select “Connect”
to view detailed instructions.
B. Validate that /etc/hosts contains the IP of your Management that the Aggregator would
face. Otherwise, add/fix.
Required line in /etc/hosts:
<Management_Public_IP> gc-management
C. Validate connectivity from the Aggregator to the Management:

nc gc-management 443 -vv

Step 4 - Configure the Management software

A. Execute
mgmt-setup -m -s
Note: the -m -s flags skip the configuration of network settings that were already
configured by AWS and the root password config. You will have to configure the root
password manually. (-m is for managed host, -s is for saas environment)
B. Click OK to go through the wizard steps.
C. Define the IP addresses that should be allowed to connect to the Aggregator over SSH
(port 22). To allow all, add 0.0.0.0/0 .
Note this setting sets iptables rules on the Management, which is also subject to a network
policy defined by the AWS Security Groups associated with the instance.
D. Configure default iptables Management policy (optional).

iptables for you.
E. Pick Guardicore Secure Communication Password for communicating with other

components:

F. Enter a password for the UI Admin user:
G. Enable Guardicore Reputation Service if needed:
H. Name the environment for the Centra system- The name that will be used and appear on
top of the page while logged in to the UI:
I. Pick type of installation- All In One- all services installed in one management server, or
Cluster- management services are divided through a cluster in the internal network.
For more details please refer to the original installation guide and follow the networking

procedure for a clustered installation, as there are more prerequisites for networking
between the components, such as configuring connection between the management
controller and the rest of the cluster, naming the instances etc.
J. Click yes to start the setup, and OK on the next screen to start the setup:
K. The setup wizard is done and will commence the installation now, after which your
Management server will be ready for use.

2.2.3 Aggregator server deployment
Step 1 - Launch an EC2 instance for the Aggregator
A. Log in to your AWS web console and select the destination region for the Aggregator
deployment.
B. Select Compute → EC2 to view your EC2 instances dashboard.
C. Launch a new instance:

a. Step 1: choose AMI. Select “My AMIs – AMIs shared with me” and locate the AMI shared
by GuardiCore. You can find it by searching “GuardiCore” or by using the AMI-ID (all your
AMIs are listed in EC2 Dashboard → Images → AMIs → Private)
b. Step 2: choose Instance Type. Select instance type, with EBS volume.
i. Standard requirement for an Aggregator is 4CPU, 4GB RAM, 30GB Storage.

However, AWS recommended EC2 type for cost savings is “t3.medium”, which
supports CPU burst usage.

ii. In case a “Mega Aggregator” is needed, make sure the VM is provisioned with 32GB
of RAM and 12 vCPUs.
c. Step 3: configure Instance Details. Mandatory fields are:
i. Network: choose the VPC of the EC2 instances that will be deployed with Agents.
i. If you are creating a new VPC, see Appendix 1 at the bottom.
ii. Subnet: choose the subnet of the EC2 instances that will be deployed with Agents.
i. If you are creating a new Subnet, see Appendix 2 at the bottom.
iii. Auto-assign Public IP:
i. If there are agents that cannot reach the Aggregator’s VPC IP (i.e not in
AWS)- choose Enable.
ii. If the agents are on AWS or you are not sure- choose Disable. You may
always allocate a public (elastic) IP after the instance is created.
iv. Under Network Interfaces, a single interface should be connected, configured with
a single IP (which can be Auto-assigned).

d. Step 4: Add storage. The required storage parameters are included in the AMI, default is
30GB. No need to change this, proceed to step 5.
e. Step 5: Add tags. Add a Name (example value: GC_Aggregator_X). Additional tags can be
added according to customers conventions.
f. Step 6: Attach Security Groups. The SG should allow the following:
i. Inbound: Port 22 (SSH) from company’s CIDR
ii. Inbound (recommended): Port 22 (SSH) from the Management IP.
iii. Inbound: Port 443 (HTTPS) from CIDR that will be covered by Agents. It is common
to allow 443 from any (0.0.0.0/0).
iv. Inbound: Port 22 & 443 from Aggregator's subnet CIDR.

v. Outbound: By default, AWS SG allows any outbound communication. To validate

this, check the outbound configuration of the SG (from EC2 dashboard, Network &
Security → Security Groups) Following successful setup of the Aggregator, this may
be locked down to Port 443 (HTTPS) to Guardicore Management IP Address.
g. Step 7: Review the settings and launch the instance. To allow the connection to the
instance, you will be requested to choose an existing key-pair in the account or to create a
new key-pair.
Step 2 - *Optional* Generate an Elastic IP and associate it with the

Aggregator
A. Create a new Elastic IP from Network & Security → Elastic IPs (“Allocate a New Address”).
B. Right click on the address and associate it with the Aggregator instance.

Step 3 - Connect to the Aggregator and validate connectivity

A. Connect to the Public IP of the Aggregator via SSH, using the key-pair and user ubuntu.
Note: You will need to run chmod 400 <key-pair.pem> before connecting.
Note: Go to Instances → Instances, select the Aggregator, right click and select
“Connect” to view detailed instructions.
B. Validate that /etc/hosts contains the IP of your Management that the Aggregator would
face. Otherwise, add/fix.
<Management_Public_IP> gc-management
C. Validate connectivity from the Aggregator to the Management:

Step 4 - Configure the Aggregator software

A. Execute
aggr-setup -m -s
configured by AWS and the root password config. You will have to configure the root
password manually. (-m is for managed host, -s is for saas environment)
B. Click OK to go through the wizard steps.
C. In Component Type, select Agents Aggregator:

D. Select the features you want the Aggregator to activate on its associated Agents:

selected.


capabilities.
E. Enter the IP address of the Management Server in the GuardiCore Cloud, provided by
GuardiCore:

F. Enter the Secure Communications password, provided by GuardiCore
G. Define the IP addresses that should be allowed to connect to the Aggregator over SSH
Note this setting sets iptables rules on the Aggregator, which is also subject to a network
policy defined by the AWS Security Groups associated with the instance.

H. In the Advanced Settings, configure any setting you wish to change/use. Otherwise, select
‘Continue’.
a. Under hostname, write the hostname you wish to use for the Aggregator
b. If you wish to use an FQDN for the Aggregator, do so here (lower-case characters
are preferred).

I. Click Yes to allow Agents to communicate against the Aggregators public IP (for instance,
Agents from a different VPC / from outside AWS). In case only inter-VPC Agents are
expected, click No.
a. If you selected YES, type the Public IP address of the Aggregator.

J. Select the roles you wish to assign to the Aggregator:
27.
Role Description

information.



K. Click Yes to continue or No to edit your configuration:
L. Choose Other Cluster ID, with indicative name (for instance: AWS_VPC_1):
Mega Aggregators
at the end.





2.3 Hyper-V installation

Depending on the type of Installation, at this stage you can begin deploying Centra components.
For On-Premises and On-Premises with Distributed Management Cluster, the first component to
deploy is Management. For SaaS installations, Management is in the cloud and doesn’t require
installation.
This section includes subsections for both On-Premises Configuration, and Distributed
Management Cluster configuration.
Note: Obtain IPs for On-prem components: Management Server, Deception Server, Collector(s), and
Aggregator(s) prior to commencing the install process as these IP addresses will be used during the
Note: Hyper-V installation uses VHD/VHDX files that are supplied by Guardicore. Contact your professional
services engineer for a download link.
Note: the Deployment procedure describes the deployment of a generic VM in Hyper-V, in this example- the
management AIO instance. The deployment procedure for every other component is similar except for the
server sizing and connectivity requirements as listed in the requirements section in the beginning of this
guide.
This procedure has been tested on Windows Server 2012 R2 and Windows Server 2016 64-bit.
Note : Deception Server can’t be imported on Windows 2012 R2 (Nested Virtualization does no exist on
Windows 2012 R2
To use Deception, Use Windows Server 2016 and see the specific section of that document.

2.3.1 Deployment procedure
1. Once downloaded, copy the files needed for the deployment to your Windows 2012 R2 / 2016 64-bit server.
2. Start your Hyper-v Manager, create your VM and name it correctly.

3. Choose “Generation 1”
4. Amount of Memory (For the Management 32 GB = 32768 MB).

Note: for an AIO deployment- configure the memory for the VM with 32GB.

5. Use an existing disk and select disk 1 of the Management VM

6. Your VM is ready for deployment. Before starting it, continue the guide for further configurations.

IMPORTANT : Before starting the Machine, you need to modify the settings.
7. On the right panel, click on “settings…”


8. Add the second disk of the Management by clicking on “IDE Controller 1”, select “Hard Drive” and click
“Add”
Select Disk_2 of the Management VM


9. Validate by clicking “apply”

10. Change the number of Virtual Processors “8” minimum for the Management

11. You can clean the VM by deleting the “scsi Controller”, deleting “DVD Drive”.
Don’t forget to apply all changes.

Your VM should look like this:
Guardicore Management VM is ready to use.

12. In order to add another network interface to the VM, gp to the “Add hardware” tag in the top and add
another interface. After adding the interface- select your desired network to connect to via the new
interface,
Note :
For Aggregator, memory will be 4096 MB
For the deception server, memory will be 32768 MB

Deploying vhd Deception Server

1. If you want to deploy Deception server on Hyper-V:
a. Windows Server 2016 is mandatory. Hyper-V Version 8.0 or greater is required
b. The Deception Server requires Nested Virtualization. This feature is only available on
Intel® Processors.
2. When the Deception VM is created and set. Before starting the installation, hyper-V Parameter
must be changed. To do it:
Open PowerShell and execute the command below (Name of the VM is deception)
# Get-VMProcessor -VMName deception | fl *
You should have this kind of result :
VMCheckpointId : 00000000-0000-0000-0000-000000000000
VMCheckpointName :
ResourcePoolName : Primordial
Count :8
CompatibilityForMigrationEnabled : False
CompatibilityForOlderOperatingSystemsEnabled : False
HwThreadCountPerCore :1
ExposeVirtualizationExtensions : False
Maximum : 100
Reserve :0
RelativeWeight : 100
MaximumCountPerNumaNode :8
MaximumCountPerNumaSocket :1
EnableHostResourceProtection : False
OperationalStatus : {}
StatusDescription : {}
Name : Processor
Id :
Microsoft:15C5F136-E774-40AF-A116-2283E4CA080E\b637f346-6a0e-4dec-af52-bd70cb80a21d\0
VMId : 15c5f136-e774-40af-a116-2283e4ca080e
VMName : Deception
VMSnapshotId : 00000000-0000-0000-0000-000000000000
VMSnapshotName :
CimSession : CimSession: .
ComputerName : WIN-INABEVB39G5
IsDeleted : False
Look for “exposeVirtualizationExtensions. If the value is false, it won’t work.

This value must be “true”. To modify it, execute the command
# Set-VMProcessor -VMName deception -ExposeVirtualizationExtensions $true

2.3.2 HyperV components installation

Note: After initial deployment of the Centra management cluster, advise with the Professional
Services team for the latest “Service Pack” version, obtain the needed files and install the package
according to Appendix B.

2.3.3 On-Premises Configuration (AIO)
1. Make sure the Management server VM was provisioned using the appropriate VHD, and
that the compute specs and networking are set as required (see the section on Enabling
Optional Services below before starting) .
2. Turn on the Management Server VM and open the console.
User : admin
Note:
● After the root user’s password is set in step 4 below, the àdmin` user will be disabled.
● After system boot, the installation wizard will wait for the docker service to be ready in
order to start. This may take up to 5 minutes, during which you might not be able to login
The Setup Utility is displayed:

5. Type a new root user password for the machine and click OK. The password should consist
of at least 6 characters and contain both upper and lowercase letters and numbers, but no
punctuation marks or other symbols. You will be asked to enter your password selection
twice.
6. Click OK; the following is displayed:
7. Click Yes to configure the network interfaces. The following is displayed:

8. Select Static and click OK to set the Guardicore Network interface manually as in the
following example:
A similar wizard will display for each connected interface. Repeat interface configuration for all
connected interfaces.
Note: Having more than two network interfaces for the management is not supported.

Note: Steps 9-10 will only appear if you have more than one network interface for the
Management server.
other Guardicore Centra components:
10. Select the interface matching the External Network - used for users’ connectivity to UI /
REST API / SSH.

iptables for you.

12. Set a Guardicore Secure Communication Token_ID (password). This will be used by Centra
components to authenticate against the Management Server during installation.
Note: Use only alphanumeric characters for the Token_ID (password)
13. Set a password for the UI default admin user:
15. Click Yes to enable the Guardicore Reputation Service.
Note: this setting can later be changed from the UI.

16. You must click Yes to enable the Segmentation Policy Enforcement feature. Selecting No is
no longer supported. The following is displayed:
17. Type a name for the environment. The name will be used during the integration with
Guardicore’s health monitoring system and should be later coordinated with a Guardicore
representative.
Note: Selecting an environment name is optional. You can skip setting a name by leaving the text
empty.

19. Select AIO (All in One) installation. The following is displayed:
20. Type the Management IP in the Guardicore Internal Network and click OK:
21. Click Yes to continue or No to edit your configuration. After clicking Yes, the following is
displayed.

22. Click OK to start the installation. Installation execution can take up to 30 minutes:
After the installation is complete, you can log in into Centra’s UI using the user admin and the
password you chose.
Note: It is possible to replace the UI certificate with your own (customer) certificate. In order to
do it, create a support ticket. You will be emailed as soon as the request is received.

2.3.4 On-Premises Distributed Management Configuration
For efficiently installing Centra in a Distributed Management configuration, follow these steps:
B. Provision the Machines and Create an IP-plan
3. Make sure you have provisioned the required machines as detailed in the section
Requirements for Distributed Management Cluster.
4. Create an IP-plan so that each member of the cluster has an IP you can assign during the
C. Deploy VMs from VHD and Configure Networking
The objective of this step is to provision all required VMs from *.VHD templates and connect the
VMs to the network, so all subsequent steps can be done remotely over SSH sessions.
10. Deploy the Management Control node from the VHD.
Expected VHD name: GuardiCore_Management_Server_<version>.vhd
11. Deploy each of the Management Distributed Nodes from the Distributed nodes VHD.
Expected VHD names:
Worker node: Guardicore_Managemenet_Node_U18_200gb.vhd
RabbitMQ node: Guardicore_Managemenet_Node_U18_200gb.vhd
InfluxDB node: Guardicore_Managemenet_Node_U18_200gb.vhd
MongoDB node: Guardicore_Managemenet_Node_U18_1tb.vhd

ElasticSearch node: Guardicore_Managemenet_Node_U18_1tb.vhd
12. Turn on all the deployed Management Cluster VMs, and login with the following
credentials:
User : root
13. Make sure the time on each node is correct and synched with the Control node. You can
achieve this either by manually setting the time on each node or by ticking the
“Synchronize guest time with host” box in the VM options of the machine, under Settings
(in the Vsphere Client). Failing to accomplish this stage on all nodes will result in a failed
installation.
14. On each machine, configure the network interfaces according to the deployment IP-plan.
Using “ifconfig -a”, identify which MAC address is assigned to each logical interface,
comparing those with vSphere settings to identify the interfaces that should be configured
according to the IP-plan.
Make sure the network interfaces are up and running by performing:
ifconfig eth0/1.. up
and confirm with ifconfig again.
15. Do the following to reconfigure Netplan:
a. Run the following command to disable Netplan’s SaaS config:
echo "network: {config: disabled}" >

/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
b. Remove the existing Netplan configuration:
rm /etc/netplan/*

c. Update the /etc/netplan/01-network-card.yaml configuration file for your network

using vi or nano editors. Here are some examples:
######################################################################################
######################################################################################
##########################
## Examples:
## Example 1 - Use DHCP
#network:
# ethernets:
# ens160:
# addresses: []
# dhcp4: true
# version: 2
### Example 2 - Use a static IP address of 192.168.1.1 with a gateway of

192.168.1.254 and netmask of 255.255.255.0, also add 8.8.8.8 as the nameserver
network:
ethernets:
ens160:
addresses: [192.168.1.1/24]
gateway4: 192.168.1.254

dhcp4: no
nameservers:
addresses: [8.8.8.8]
version: 2
## Example 3 - On ens160 uUse a static IP address of 192.168.1.1 with a gateway of

192.168.1.254 and netmask of 255.255.255.0, also add 8.8.8.8 as the nameserver, and
on ens192 use DHCP
#network:
# ethernets:
# ens160:
# addresses: [192.168.1.1/24]
# gateway4: 192.168.1.254
# dhcp4: no
# nameservers:
# addresses: [8.8.8.8]
# ens192:
# addresses: []
# dhcp4: true

# version: 2
###################################################################################
###################################################################################
Note - the nameservers configuration is optional. If multiple DNS servers are needed, separate
them with commas.
16. Restart the network interface for the change to take effect:
netplan try
17. Restart the VM using reboot.
18. Connect to each instance remotely using SSH. To do this, follow the instructions in the next
section (Preconfiguration of Management Nodes). After completion, you will be ready to
run the setup wizard from the Control.
D. Preconfigure the Management Cluster Nodes
In this step you configure hostnames for the Management cluster nodes, reset the root password,
and sync SSH keys from the Control. You will then be ready to run the setup wizard.
Configure Hostnames
On each of the Management cluster node instances (excluding the Control), configure a
meaningful hostname. A suggested naming scheme is provided here, although you may want to use
alternative hostnames that comply with the company policy instead.
● Worker node: gc-Worker-1
● RabbitMQ nodes: gc-rabbit-1, gc-rabbit-2
● InfluxDB node: gc-influx-1
● MongoDB nodes: gc-mongo-1, gc-mongo-2, gc-mongo-3

● ElasticSearch nodes: gc-elastic-1, gc-elastic-2, gc-elastic-3
Configure as following:
5. Run the following, replacing <HOSTNAME> with the new hostname:
hostnamectl set-hostname <HOSTNAME>
NOTE: If you get “Failed to create bus connection: No such file or directory” then simply
reboot, log back in, and then retry.
6. Edit /etc/cloud/cloud.cfg changing preserve_hostname from false to true
7. Edit the line containing the loopback IP address in the file /etc/hosts.
Replace
127.0.1.1 gc-management-node
with
127.0.1.1 <NEW_HOSTNAME>
8. Verify that the new hostname has been configured: hostnamectl

Note: to see the new hostname displayed in the prompt, reconnect to the node using
SSH.
Reset Root Password

Change the root password of each of the nodes using passwd
Sync SSH keys from the Control

2. Login to the Control server with the following credentials:
User : root
25. Allow passwordless SSH login from the Control node to all the other nodes, by running the
following command on the Control node for each node:
ssh-copy-id <Node IP>

E. Configure the Management Cluster

Configuring the Management Cluster requires the following:
● Run the Setup Wizard.
● Adjust the ElasticSearch Cluster Heap Size.
● Configure the RabbitMQ Redundancy Cluster.
● Configure the MongoDB HA Cluster.
Instructions for these procedures are provided below.
Run the Setup Wizard

On the Management Control:
1. Start the installation setup wizard by running the command
mgmt-setup
2. The Setup Utility appears:
Click OK and select a new root user password for the machine. You will be asked to enter your
password selection twice:

26. Click Yes to set the root password and disable the default “admin” user:
27. Click Yes to configure the network interfaces

30. A similar wizard will display per each connected interface. Repeat interface configuration
for all connected interfaces.
Note - more than two network interfaces configuration is not supported.
Note: Default gateway should be set Only on one interface, usually on the external interface!!!
other Guardicore Centra components.
32. Select the interface matching the External Network - used for users connectivity to UI /
REST API / SSH:

SSH (port 22). To allow all, add 0.0.0.0/0:
iptables for you.

35. Set a Guardicore Secure Communication password. This password should be a secret
password, used by Centra components to authenticate against the Management Server
during installation. Please use only alphanumeric characters for passwords.
36. Set a password for the UI default admin user.
37. Click Yes to enable the Guardicore Reputation Service. Note that this setting can be later
changed from UI.

38. Entering the environment name is optional. You can skip it by leaving the text empty. If
entered, the name is used during system health monitoring integration, and should later be
communicated to Guardicore representative.
39. Select Cluster (Distributed Management) installation.
40. Type the Management IP in the Guardicore Internal Network.

41. Enter Management Worker nodes IP addresses. Make sure to also include the
management Control IP in the Workers list.
Note: In the next steps (19-22), you configure the IP of each dedicated external node. The
controller node’s IP should only be included in the list if the controller node is planned to
take one of these roles.
42. Enter MongoDB node IP address. If the deployment requires more than one MongoDB
node, enter only the IP of the 1st MongoDB node, and configure a RabbitMQ Redundancy
Cluster or a MongoDB HA Cluster after this step is complete.
43. Enter ElasticSearch node/nodes IP address/es.

44. Enter InfluxDB node/nodes IP address/es. Note - in case the influxDB node will run on the
Management Control node, specify the Management Control’s IP. Leaving this screen
45. Enter RabbitMQ node IP address. If the deployment requires more than one RabbitMQ
node, enter only the IP of the 1st RabbitMQ node, and see Configuring RabbitMQ
Redundancy Cluster for adding an additional node after this step is complete.
46. Enter Postgress Daily Flows node IP address. In case there is no external node for the
Postgress service- fill in the Management Control node’s IP address. Leaving this screen

47. Click Yes to continue.
48. Click OK to start the installation (ignore the “Setup completed” message). Installation
execution can take up to 60 minutes.

Note:
In case the flow is interrupted with the following error:
Upgrade failed on state “START_CLUSTER_INFRA”, check
“/var/log/guardicore/upgrade_service.log”
Wait 5 min and run:

gc-patch-resume
27. Set Management configuration to utilize all Elastic nodes:
gc-cluster-cli service-scale --service_name elasticsearch

--instances <NUMBER OF ELASTIC SEARCH NODES>
28. Validate the UI is accessible by connecting to Centra UI by browsing to the Control node’s
external interface IP over port 443. Note: There is an option to replace the UI certificate by your
own (customer) certificate. Click here to create a support ticket. You will be emailed as soon as we
receive your request.
29. Validate full Management cluster health by running on the Control:
gc-cluster-cli health
Adjust ElasticSearch cluster heap size

For ElasticSearch clusters of size 3 and higher, with each node having 32GB, the jvm heap size
allocation should be increased from 8BG (a default value for all-on-one Management) to 20GB.
On the Management Control node:
4. Edit the file /etc/guardicore/guardicore_setup.conf
Locate the configuration "override_es_heap_size": 8, and change it's value
to 20.
5. Edit the file /etc/guardicore/cluster/resources.json

Locate elasticsearch and change “memory”: 20000 to “memory”: 28000

6. For the change to take effect:
gc-cluster-cli infra-service-restart --infra_name cluster-manager
gc-cluster-cli service-restart --service_name elasticsearch
Configure RabbitMQ Redundancy Cluster

Register a standby RabbitMQ node used for redundancy. In this configuration, in case the primary
RabbitMQ node fails, the cluster manager (executed on the Control) injects RabbitMQ into the
standby node which automatically replaces the primary one. The median time before a new
RabbitMQ will replace the primary one should not typically exceed 3 minutes.
Setup
Execute the following command on Control to configure a standby RabbitMQ node:
gc-cluster-cli add_node --node_type rabbitmq --node_address
<Standby_RabbitMQ_IP>
Validation
This command should perform the following actions:

/etc/guardicore/guardicore_setup.conf on the Management Control

/etc/guardicore/hosts on the Management Control server
● Adds the true indicator to the rabbitmq line of the file on the second RabbitMQ host:
/etc/guardicore/cluster/attributes
Note: Be aware that in case of a failover process, existing unprocessed messages in the queue
will be lost.

Configure MongoDB HA Cluster

By default, MongoDB is installed in Guardicore as a stand-alone node. When HA is necessary,
MongoDB can be extended to a cluster of 3 nodes in HA replica-set configuration. A replica-set
refers to a group of MongoDB servers that operate as a cluster and replicate data. The replica-set
meets both redundancy and failover requirements. Each node in the replica set has a role, in this
case, either Primary or Secondary:
The primary MongoDB server is the "Control" node. It is the only MongoDB that is allowed to write
data and all writes go through this MongoDB node. Whenever a replica set is installed, an
election process is held to elect the primary MongoDB server. This will also happen if the current
primary dies.
The secondary server replicates data from the primary node. Secondary servers are not allowed to
write. A secondary server can become a primary node via an election process. (assuming it's
configuration allows it).
When there is a successful Failover (i.e. when the primary node fails and cannot communicate with
the rest of the cluster secondary nodes for more then 10 sec, by default), a new primary node is
elected.
Setting up the MongoDB replica-set for Guardicore requires four stages:

Stage 1: Check prerequisites.
Stage 2. Initialize the Replica-set.
Stage 3: Add members to the Replica-set.
Stage 4: Start the Replica-set cluster.
The four stages and their steps are provided below:
Stage 1: Check Prerequisites
3. Make sure that all MongoDB replica set nodes are available via ssh and will not require
a password. You can use the following command to do this:
ssh-copy-id <node_address>
4. Make sure that the iptables will allow the 27017 (TCP) traffic between these nodes.
Stage 2: Initialize the Replica Set
To initialize the MongoDB replica set:

3. On the Control management node run the following command:
gc-mongodb-cluster-cli init
This will create a replica set with a single MongoDB node.
Note: When running init, the app group is stopped to avoid CPU spikes due to the
interruption of MongoDB service.
Note: If the initialization of the MongoDB replica set fails following the previous command,
use the next walkaround:
export IMAGE_TAG=$(python -OO
/var/lib/guardicore/management/docker_deploy/scripts/cluster/startup
/helpers/get_image_tag.pyo -i gc-service)

export REGISTRY_IP=$(python -OO

/var/lib/guardicore/management/docker_deploy/scripts/registry/get_re
gistry_ip.pyo)
docker run --net=host -it --rm --entrypoint bash
"$REGISTRY_IP":5000/gc-service:"$IMAGE_TAG" -c "mongo <mongo URI
printed by the script>"
# From mongodb shell
rs.initiate({"_id": "guardicore_replica_set", "members": [{"_id": 0,
"host": "<host mongo internal ip>"}]})
# You should see { "ok" : 1 }
exit
Retry the failed command and continue with the procedure.
4. Verify the MongoDB replica set was successfully initialized using the following
command:
The result should be similar to the following
At this point there should be a single server with status Primary whose health is ok.
Stage 3: Add Members to the Replica Set
Once the replica-set has been initialized, it is ready to accept new members.
3. To add a node to the replica set & the Management cluster use the following:

gc-mongodb-cluster-cli add --node_address <node_address> --add_to_cluster
The --add_to_cluster will make sure to first add the new machine as a management cluster
node. This will do what gc-cluster-cli add_node does, just specifically for the mongodb node
type. Once the node is part of the management cluster it will be added as a member in the
initialized MongoDB replica set.
IMPORTANT:
● There is NO need to add the MongoDB replica set nodes via gc-cluster-cli.
● If the nodes were already added via gc-cluster-cli, skip passing the
--add_to_cluster flag when running the above.
4. To verify the new node successfully joined the existing MongoDB replica use the
following command:
The result should be similar to the following:
■ At this point there should be a single server with status Primary whose health is ok.
■ In addition, you should have a single server with status Secondary whose health is ok.
(above example has more nodes).
This process can be repeated for each node you want to add to the replica set.
■ It is critical for high availability to have a replica set with at least 3 nodes.
■ The number of nodes must be odd for the primary election to work (there is an arbiter
option which is not yet supported).

Stage 4: Start the Cluster
Once the process of forming the MongoDB replica set is complete and all desired nodes are a part
of the replica set issue the following command:
gc-cluster-cli cluster-restart

2.3.5 Deception Server deployment

(for on-premises configurations only)
1. Turn on the Deception Server VM and open the console.
User: admin
Password: admin
Note: After the root user’s password is set in step 4 below, the àdmin` user will be disabled.
The Guardicore Setup Wizard is displayed:
3. Click OK to go through the wizard steps. The following is displayed:
4. Type a new root user password for the machine and click OK. The following is displayed:

5. Click OK to edit the local network interfaces. The following is displayed:
6. Choose Static to set the Guardicore Network interface manually. The following appears:
7. Enter parameters for interface settings and click OK. The following appears:

8. Enter the IP address of the Management Server in the Guardicore network and click OK.
9. In the Tunnel port screen accept the default 443 port by clicking OK. The following is
displayed:
Server and click OK. The following appears:

11. Define the IP addresses that should be allowed to connect to the Deception Server over

2.3.6 Aggregator(s) deployment
Deploying the Aggregators consists of two phases:
1. Configure the Aggregator’s FQDN
2. Deploy the Aggregators
Configuring an FQDN for the Aggregator has the following benefits:
● It makes it easier to achieve Aggregator HA - once one of the Aggregators is unavailable,

the Agents that were connected to it will re-query the DNS and reconnect to another
Aggregator.
● It is sometimes necessary to add additional Aggregators to the cluster (to support

expansion, etc). When Agents are installed against FQDN, adding a new Aggregator does
not require any configuration change on the Agents’ side - just add the Aggregator’s IP to
the DNS record.
Create FQDN(s) Record

Register a DNS A-record that includes an entry for each Aggregator in the cluster. This would
result in the following DNS results:
[root@localhost ~]# nslookup aggr.cus-xxxx.cloud.guardicore.com

Address: 35.193.234.123
Address: 35.183.204.118
In case an alternative solution such as GSLB is used, create the FQDN alias record in the GSLB.

Note: If the Aggregator was installed using the wizard prior to configuration of the FQDN, it is
possible to add the FQDN of the Aggregator’s cluster after the installation process. Refer to the
guide for configuring the Aggregator FQDN on an installed Aggregator.
Deploy Aggregators
RAM and 12 vCPUs.
If not, stop the VM and change the resources consumption via “Edit settings”.
The Mega-aggregator is used to handle ~ 2000 Agents, with deception disabled. Please
note this when assigning responsibilities to the Aggregator in the installation wizard.
4. Turn on the Aggregator VM and open the console.
User: admin
Password: admin
Note: After the root user’s password is set in step 4, the àdmin` user will be disabled.
7. Select a new root user password for the machine:



selected.

capabilities.


10. Click OK to configure the network interfaces:
11. Choose Static to set the Guardicore Network and the Agent facing interfaces manually.
A Static IP should be reserved in the customer’s network.

13. A similar wizard will be shown per each connected interface. Repeat interface
configuration until all connected interfaces are set.
Server:


28.
Role Description

information.

include this prompt..

InventoryAPIOrchestEnable Aggregator participates in naming assets using an

orchestration achieved by a REST API method.
Agentless assets will appear as if they arrived from a
regular orchestration.
21. Provide a list of FQDN addresses for the Aggregator:
22. If the Aggre gator has a NAT facing the Agents, enter its IP address here:

25. At some point during the installation, the Cluster ID box appears:
26. Choose the Cluster ID for the Aggregator. If you do not have multiple
Collectors/Aggregator clusters, choose ‘default’.
NOTE: The design of how Collectors/Aggregators are assigned to clusters should be done
in consultation with Guardicore Professional Services/Customer Success.
Mega Aggregators

at the end.



2.4 Azure installation

About this Section
This section provides detailed instructions on how to install and deploy a Centra Aggregator in the
following configuration
● Azure based Aggregators, communicating with a Management server which is deployed on

a different infrastructure.
2.4.1 Preconditions
1. Administrative access to the Azure Subscription and Resources.
2. Azure VHD of the Aggregator component is shared by Guardicore with the customer.
3. Microsoft Azure Storage Explorer for uploading the VHD onto the Azure platform.
a. Download and install the software on your machine.
4. Guardicore CentraTM Management has been set up for the customer.
5. *Azure Server with Internet access, sufficient storage (depending on component VHD), and
Microsoft Azure Storage Explorer installed
* - Recommandation
2.4.2 Installation steps
2.4.2.1 Upload VHD of the Aggregator to Azure platform using Microsoft

Azure Storage Explorer
1. Download the Azure VHD from Guardicore’s Customer Portal and save it locally
2. Upload the VHD to a Disk on your Azure Platform using Microsoft Azure Storage Explorer
using the follow the steps:

a. Connect to Azure Subscription

i. Launch Azure Storage Explorer and click the plug-in icon on the left
(Open Connect Dialog):

ii. Select Add an Azure Account, and then click Next.
iii. In the Azure Sign in dialog box, enter your Azure credentials.

iv. Select your subscription from the list and then click Apply.
b. Upload the VHD to a managed Disk

i. On the left pane, expand Disks and select the resource group that
you want to upload your disk to.

ii. Select Upload.
iii. In Upload VHD specify your source VHD, the name of the disk, the
OS type (select Linux), the region you want to upload the disk to, as

well as the account type (works with both HDD and SSD). Select
Create.
iv. The status of the upload will now display in Activities.
v.
If the upload has finished and you don't see the disk in the right pane,
select Refresh.
3. Troubleshooting
a. If you do not have permissions to upload a VHD directly to a Disk, upload it to a
Blob, then create a managed Disk from the VHD blob following this guide:

https://aidanfinn.com/?p=20441
NOTE: Make sure to select the type of disk to be gen1 and not gen2, as gen1
uses BIOS while gen2 uses UEFI which is not supported.
b. If you are uploading from a local server (not an Azure server), and receive the
following message:
{"code":"DeploymentFailed","message":"At least one resource deployment
operation failed. Please list deployment operations for details. Please
see https://aka.ms/DeployOperations for usage
details.","details":[{"code":"BadRequest","message":"The specified cookie
value in VHD footer indicates that disk
'Guardicore_Aggregation_Server_49150.vhd' with blob
https://xxxxx.blob.core.windows.net:8443/guardicoreimage/Guardicore_Aggre
gation_Server_xxxxx.vhd is not a supported VHD. Disk is expected to have
cookie value 'conectix'."}]}
It is most likely caused due to a connectivity issue \ timeout, breaking the upload.
Make sure you have a stable connection and that your computer does not go to
sleep. If the issue persists, please retry uploading the VHD using an Azure
Server as recommended
c. If uploading still fails, please make sure the following permission settings are
valid:
i. The user has the necessary permissions to Create a Disk
ii. There are no Disk Access restrictions refraining the user from uploading
iii. There are no Locks on the Resource Group or Resources

2.4.2.2 Create a VM from the VHD
1. Create the VM
a. From the Azure portal, on the left menu, select All services.
b. In the All services search box, enter disks and then select Disks to display
the list of available disks.
c. Select the disk that you would like to use. The Disk page for that disk opens.
d. In the Overview page, ensure that DISK STATE is listed as Unattached. If it
isn't, you might need to either detach the disk from the VM or delete the VM

to free up the disk.
e. In the menu at the top of the page, select Create VM.
2. Basics
i. Enter a Virtual machine name and either select an existing Resource
group or create a new one.
ii. Select a VM size.
1. Standard requirement for an Aggregator is 4CPU, 4GB RAM, 30GB
Storage. However, Azure recommendation for VM size for cost
savings is “B2ms”, which supports CPU burst usage.
2. In case a “Mega Aggregator” is needed, make sure the VM is
provisioned with 32GB of RAM and 12 vCPUs.

iii. In Inbound port rules None can be selected, we will attach a Security Group
later on.

3. Disks
i. Create and attach a new Disk
ii. Select a disk with 32GB, we recommend using an SSD
4. Networking
i. Either create new resources through the portal or select existing
ones for

1. Virtual network
2. Subnet
3. Public IP
ii. Choose Advanced NIC network security group, and either create a
new SG or choose an existing one.
The Security Group should allow the following:
1. Inbound: Port 22 (SSH) from company’s CIDR
2. Inbound: Port 443 (HTTPS) from CIDR that will be covered by
Agents. It is common to allow 443 from any (0.0.0.0/0).
3. Outbound: By default, Azure SG allows any outbound
communication to the Internet. To validate this, check the outbound
configuration of the SG (from EC2 dashboard, Network & Security
→ Security Groups) Following successful setup of the Aggregator,
this may be locked down to Port 443 (HTTPS) to Guardicore
Management IP Address.
4. By default a new Security Group enables any inbound and outbound
traffic within the Vnet, this may be modified to your needs

5. Other
a. Skip Management configuration phase.
b. In the Advanced configuration, validate the type of VM created is gen1, otherwise-
redeploy the disk from which the VM is created as gen1.
c. Add Tags if relevant
d. Review + Create the VM
e. Wait on this screen until the system notifies you the resource has been created.
2.4.2.3 Connect to the Aggregator and validate connectivity
1. Connect to the Aggregator via SSH and validate connectivity

a. Click on- Go To Resource.

b. Left pane, scroll down to Reset Password

To create a new user: fill in the username and password, press Update.
Note: The user will have sudo privileges
c. SSH to the Aggregator IP using the user created

ssh <user>@<Aggregator_IP>
d. Run
sudo su
e. Validate that /etc/hosts contains the Aggregator facing IP of your Management.

Otherwise, add/fix.
<Management_IP> gc-management
f. Validate connectivity from the Aggregator to the Management:

2. Troubleshooting SSH not working (Skip to step 4 if SSH worked)

a. Enable Serial Console

i. Go to the Boot Diagnostics settings

ii. Choose Enable with custom storage account
iii.Create a Diagnostics storage account, example for low-cost account

1. Pick a name
2. Kind: Storage (general purpose v1)
3. Performance: Standard
4. Replication: LRS
b. Access Serial Console
i. Enter your username and password to login

ii. You may need to press enter if you are not prompted with login input
c. Switch to root: sudo su

d. Change or remove network interface from iptables:
i. Edit iptables: vim /etc/iptables/rules.v4
ii. Change -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT to
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT (Deleting -i eth0
part)
iii. Update iptable: iptables-restore < /etc/iptables/rules.v4
e. Go back up to Step 3, Section 1, Subsection b-e
2.4.2.4 Configure the Aggregator software

1. Execute
aggr-setup -m -s
configured by Azure, and skip resetting the root user’s password of the machine. (-m is for
managed host, -s is for saas environment)


selected.


capabilities.
5. Enter the IP address of the Management Server in the GuardiCore Cloud, provided by
GuardiCore:

6. Enter the Secure Communications password, provided by GuardiCore
policy defined by the Azure Security Groups associated with the instance.
8. In the Advanced Settings, please configure any setting you wish to change/use. Otherwise,
select ‘Continue’

are preferred).

9. Click Yes to allow Agents to communicate against the Aggregators public IP (for instance,
Agents from a different Network/ from outside Azure). In case only inter-Azure Network
Agents are expected, click No.

29.
Role Description

information.



12. Choose Other Cluster ID, with indicative name (for instance: Azure_Network_1),
otherwise, the installed aggregator will try to connect to the wrong cluster manager-
unsuccessfully:
13. If the Aggregator is a “Mega Aggregator”, perform the following steps:
at the end.

monicore-ctrl restart gc-enforcement.
monicore-ctrl restart gc-cluster-mgr.




2.5 GCP Installation

About this Section
● GCP based Aggregators, communicating with a Management server which is deployed on a

2.5.1 Preconditions
1. Administrative access to the organization’s GCP console.
2. GCP image of the Aggregator component is shared by Guardicore with the customer /
downloaded from the customer portal and uploaded to the client's project.
Contact GC prior to installation in order to receive the image.
3. Connectivity requirements, FIREWALL RULES of the aggregator’s network:
a. Ingressing traffic, allow 80, 443 as needed.
b. Ingressing traffic from internal networks as needed.
c. Ingressing traffic via port 22 for administration causes, as needed.
2.5.2.1 Create a VM from the image

1. GCP left toolbar: Compute Engine > VM instances.
2. Top pane: Create Instance.
3. Left pane: New VM instance

4. Minimum machine configuration: E2 series, 4vCPU, 4GB memory, 30GB storage.

5. Boot disk > Custom image > show images from uploaded project > select image of
aggregator.
RAM and 12 vCPUs.
7. Click on the next link to open the next menu:
a. Security: The aggregator image comes with a password and does not include SSH
keys.
b. Networking:
i. Network Interfaces- add the needed interfaces in order to connect to the
internal network, administration network etc.
ii. Configure needed subnets.
iii. Create internal IP + External IP (as per client’s requirements /
configuration). Ephemeral external- automatic external IP.
iv. Click on Done to complete the networking configuration.
8. Click Create to commence creation of the instance.
9. Validate internal and External IP created.
a. In order to anchor the Ephemeral IP to the aggregator and make it static, go to VPC
> External IP addresses, and change “Type” to Static.
This is recommended in order to keep the IP to the aggregator in case of a reboot.

1. Connect to the aggregator via SSH.
User: root
Password: GuardR00t111
2. Execute
aggr-setup -m -s

configured by Azure, and skip resetting the root user’s password of the machine. (-m is for


selected.

capabilities.


GuardiCore:
policy defined by the GCP networking configuration associated with the instance.


are preferred).

Role Description

information.



13. Choose Other Cluster ID, with indicative name (for instance: Azure_Network_1),
otherwise, the installed aggregator will try to connect to the wrong cluster manager-
unsuccessfully:
at the end.





2.6 OCI Installation

About this Section
● OCI based Aggregators, communicating with a Management server which is deployed on a

2.6.1 Preconditions
1. Administrative access to the organization’s OCI console.
2. OCI image of the Aggregator component is shared by Guardicore with the customer.
Contact GC prior to installation in order to receive the image.
3. Connectivity requirements, FIREWALL RULES of the aggregator’s network:
a. Guardicore network- to communicate with the rest of the aggregators.
This interface should receive a static IP.
b. Connectivity to agents (guests). An option to use NAT is supported. This interface
should be assigned with a static IP.
c. At least one Aggregator / Collector should be able to reach the OCI management
network. This interface should be assigned with a static IP.
4. Instance requirements for the Aggregator VM:
a. VM.Standard.E4.Flex.
b. 4GB RAM.
c. 2 OCPUs
d. 30GB Boot Volume

2.6.2.1 Creating the Centra VMs

1. Import the components software as custom image, type OCI using the PAR links supplied
by the professional services team.
2. Deploy the Aggregator software from the custom image.
a. Create a VM instance.
b. Create in Compartment as per the client’s requirements (parallel to GCP’s project).
c. Placement- Availability Domain is parallel to the “Sub-Region” criteria.
d. Image and shape:
i. Click on “Change Image”.
ii. Image source- Custom images, compartment- compartment where the
aggregator image is saved.
iii. Verify that the custom image name matches the name expected, verify the
build and version are correct (for example-
build_v36_20201216_137-guardicore-aggregator).
iv. Click on “Change Shape”.
v. Select 2 OCPU, 4GB RAM.
e. Networking:
i. Attach the appropriate networks to the interfaces as per the connectivity
requirements discussed above.
ii. Provision a public IPV4 address for the VM.
f. Add SSH keys:
i. Guardicore supplies the Aggregator image with a default root password
that can be changed during or after the installation.
ii. Click on “No SSH Keys”.
g. Boot Volume- no need to modify, as the image supplied already contains the boot
disc used.
h. Click on Create.


1. Connect to the aggregator via SSH.
User: root
Password: GuardR00t111
2. Execute
aggr-setup -m -s
configured by OCI, and skip resetting the root user’s password of the machine. (-m is for


selected.

capabilities.


GuardiCore:

policy defined by the OCI networking configuration associated with the instance.

are preferred).

Role Description

information.



13. Choose Other Cluster ID, with indicative name (for instance: OCI_cluster), otherwise, the
installed aggregator will try to connect to the wrong cluster manager- unsuccessfully:

at the end.



3 Agents deployment
3.1 Overview of Agent Installation Steps
Checks to Perform BEFORE Deployment
1 Verify communication between Agents and Aggregator.
2 Verify OS support. See Appendix A.
3 Prepare prerequisites for the OS to which you are installing.
4 Verify Available Storage Space on the Server.
5 Configure Installation Profile
Installation and Configuration
5 Follow instructions for executing Agent installation provided on the Admin GUI under
Agent Installation. Instructions for installing Windows, Linux, AIX, and Solaris Agents
are also provided in this guide in the corresponding sections below.
6 Execute the deployment.
7 Verify the deployment.
8 Troubleshoot the deployment.
The following sections provide guidelines and instructions on each of these stages.

3.2 Checks to Perform BEFORE Deployment

Verify communication between Agents and Aggregator
Verify that the network enables servers on which Agents will be installed to communicate with the
Aggregator(s) that will manage them over port 443.. During Online installation, as well as after the
installation, the Agent keeps in constant communication with the Aggregator to fulfill its normal
operation. To do that, port TCP/443 should be opened from the Agent towards the Aggregator(s)
that manages it.
Note - Depending on allocated compute resources, a single Aggregator can support the following
number of Agents:
Agent Module Configuration Average Number of Agents Supported
● Deception module is disabled 4 Virtual CPU, 4GB: 200 Agents to

● Reveal, Enforcement, and Detection 12 Virtual CPU, 32GB: 2000 Agents.
modules are active (Micro-Segmentation feature-set)
All Agent modules are active 100 Agents
Verify OS support
Verify that the OSs on devices on which Agents are to be deployed are supported. Refer to this
section for updated information.
Guardicore supports the installation of Agents on many operating systems, mainly from the
Windows, Linux and Unix families. Most operating systems support Agents with full capability,
while Agents on some legacy OSs have partial capabilities. Full support means that all four Agent

modules are supported (Reveal, Deception, Enforcement, and Detection). Partial capabilities
means that some Agent modules are not supported, or that a module is functioning based on a
legacy mechanism.
To view the full list of supported operating systems in your Centra version, do the following:
1. Open Guardicore Centra UI.
2. Enter Administration mode.
3. Under ‘Help’, select Agent Installation Instructions.
4. Scroll through the list of supported versions and select the version that exists on
the device to which you are deploying. Versions that are fully supported appear
with a green check mark. Versions that are partially supported appear with a yellow
check mark. The modules that are supported/unsupported appear immediately
under the instruction title on the right:
Closeup View:

Alternatively, see Appendix A in this document.
If the OS on a device is unsupported, the device’s security can still be covered by a Guardicore
Collector, with certain limitations (the Collector can issue alerts for violations of flow policies but
cannot enforce policies).
Verify Available Storage Space on the Server

Make sure there is enough storage space on the server on which the Agent will be deployed:
● Installation Package: 60MB.
● Agent Binaries: After installation, the Agent binaries require 60MB of system's disk space.
● Log Files: Every Agent process is logged into a separate log file. By default, an additional
220MB of disk space is required for log files storage for the default “medium” log profile.
Refer to Agent Log Rotation Profiles for more info.
Installation Profile Configuration
Overview
Agent installation profiles allow you to customize your initial Agent configuration and provide the
following benefits:
● Allow you to manage all Agent installation configurations from a single location.
● Eliminate the need for using configuration attributes as parameters for the local
installation of Agents on the server.

Installation profiles are relevant for install time only. Agent configuration can always be changed
after installation by selecting “override configuration” from the Agents screen. You can also reset
an Agent’s configuration to its profile as described in the Reset Configuration to Profile section.
Installation Profiles List
To view and manage your installation profiles, you can open the Installation Profiles page in
Centra’s Administration screen, under Agents/Installation Profiles:
The Installation Profiles screen enables you to browse available profiles, create new ones, edit
existing profiles and delete those that are no longer needed. The screen also enables you to modify
the default installation profile.
The screen displays the following columns:
Column Description
Profile Name Associates the Agent installation to a profile. See Agent Installation section for
detailed explanation.

Usage The number of Agents in the system that were installed and associated with this
profile. The number represents only Agents that are currently registered in
Centra.
Description An optional description of the profile.
Author The name of the user created the profile.
Created The date that the profile was created.
Modified The last date that the profile was modified.
Default Installation Profile
Any Agent that is installed without an installation profile is associated with the default profile.
The default profile is also used as a base profile for any customized installation profile. Each
attribute that was changed in some customized installation profile, overrides the default profile
attribute.
You can edit the default installation profile by clicking on Edit:
Note: Modifying the default profile will not affect installed Agents, but will affect any new Agent
installation, regardless of the defined profile. This is because the default profile is the base of any

custom installation profile. Attributes that were changed in the custom installation profile won’t
be affected by changes in the default profile.
Create a New Profile
You can add a new installation profile by clicking on the Add new profile button:
Now you can define the installation profile name that will be used by any Agent installation
procedure. The installation profile name cannot be changed after being created
You can now select which attribute you want to set and override. Any override will override the
value which is defined by the default installation profile. Any unchanged attribute will get a value
which is defined by the default installation profile.
When installed, any new Agent associated with this profile will have attributes as follows:
● Unchanged attributes will get the values of the Default profile.

● Attributes that were modified with override values will get the modified values of the new
customized profile.
Agent Installation
To install an Agent with an installation profile you need to specify it during installation.The Agent
will be installed with the Default installation profile in the following cases:
● No installation profile was specified.
● A previous version (4.31.X.X or older) of the Agent was upgraded.
● A non-existing installation profile was specified.
In each of these cases, a message indicating that an Agent was installed with the Default profile
will be logged in the Agent Log Screen in the Centra UI. Changing an installed Agent’s attributes by
changing its installation profile is not currently supported.
To change an Agent’s attributes, you need to override its configuration through the Override
Configuration option in the Agents screen.
To change an Agent’s installation profile, you’ll need to uninstall the Agent and reinstall it with the
new installation profile.
Note: After installation, it might take up to 5 minutes for the Agent to be initialized with its
installation profile.
Install Windows Agent with an Installation Profile
1. You can specify the installation profile through the Agent installer user interface:

2. You can specify the installation profile using the installer CLI interface:
windows_installer.exe /q /a 172.16.100.50 /p <password> /installation-profile

<installation_profile_name>
Install a Linux Agent with an Installation profile
You can set the installation profile for a Linux Agent by specifying the designated environment
variable before the standard installation commands:
export GC_LOGGING_PROFILE=<profile>
Edit an Installation Profile
You can edit installation profiles, but remember, your changes will affect newly installed Agents
only. Editing profiles does not directly affect Agents that are already installed. However, you can
reset an Agent’s configuration to its profile which will reset the configuration to the most
up-to-date profile configuration (i.e., the profile configuration that you most recently edited).
Note: If you modify the default profile, remember that it also modifies other profiles, as other
profiles are considered as modifications of the default profile.

Reset Configuration to Profile
You can always reset single, or multiple Agents’ configurations to their installation profile
configurations.
Selecting Reset to profile defaults will display a description of the operation. The listed Agents will
reset their configuration to the configuration of the profile listed in the Target Profile column:
When an Agent is installed, its profile appears in the Installed Profile column. If the profile no
longer exists, the value in the Target Profile will be default.

3.3 Manual Deployment of Agents Using the

Admin GUI
To manually install Agents on a server, follow the instructions on the Agent Installation
Instructions page:
1. In the left pane, select the OS to which you are installing. Operating Systems that appear
with a green dot indicate that they support all Agent modules (Reveal, Deception,
Enforcement, and Detection). Those that appear with a yellow dot do not support all
modules; modules that are, or are not, supported are noted underneath the Instructions
title like this:
2. On the Installation screen, select the Aggregator with which the Agent will communicate:
3. Select an Installation Profile:

Installation profiles can be created on Centra and enable installing Agents with specific
configuration settings. For instructions on how to create and manage installation profiles,
see .
4. Select whether you want to perform an online or offline installation:
5. Follow the instructions for downloading and installing the packages, for example:

Note: Before installing the packages, click Advanced Options for additional
customization options, if required:
Notes:
● In case of installing the Agent using the Aggregators cluster’s FQDN, replace the
Aggregator’s IP with the FQDN in the installation snippet. If the FQDN already points to
Aggregator’s cluster, replace the Aggregator cluster’s IP with the FQDN:
i. For Windows - windows_installer.exe /a aggregator.domain.com
/p "<installation password>"
ii. For Linux - export SSL_ADDRESSES="aggregator.domain.com:443"
● In case the Aggregator has multiple interfaces (one facing the Guardicore Management
server, and one facing the guest servers), the IP in the deployment snippet might be
pointing to the wrong interface and it might be necessary to change it manually.

3.4 Introduction to Agent Installation

For Windows and Linux, Guardicore supports two approaches for installing Agents:
Online installation: The installation flow pulls the package from the Guardicore Aggregator (that
fetches it from a repo on the Guardicore Management), then the flow installs and configures the
Agent. The installation instructions for this option per OS are included in the Guardicore UI.
“Online installation” allows installing the latest Agent version that is available in the repo on the
Guardicore Management without modifying automation scripts / packages.
OR
Offline installation: A package file is placed in the customers repo / automation platform, and
copied and installed on a target server by customer’s scripts.
“Offline installation” allows control of the deployed binaries within internal processes. It can be
also used in cases the Aggregator can’t yet be reached but the project already wants to deploy an
Agent (leaving it “orphan” until an Aggregator is available). However, the automation/package is to
be maintained with new Agent releases.
Both methods can be automated for rollout at scale within common configuration
management tools.
For AIX installation, only online installation is available using wget. For Solaris installation, both
online and offline using local files are available.

3.5 Windows Agents Installation

Windows Agents - Online Installation
Installation Script
1. Download the following file from any Aggregator in the system:

https://<agregator_FQDN>/windows_installer.exe
2. Open the Windows command prompt with administrative privileges and run the installer
with a minimal set of 2 parameters as follows:
windows_installer.exe /a <aggregator_FQDN> /p
"<agent_installation_passphrase>" /installation-profile default
Advanced installation parameters

To customize Agent installation for Windows use these flags:
/offline Installs the Agent using the version which is provided within the installer
(network connectivity to the Aggregator is not required)
/a Aggregator address. agregator_FQDN is to be provided by the Guardicore

Technical platform owner
/p Agent installation passphrase. retrieve from the Guardicore UI:

Administration → System → Configuration → Agents installation → Agents
installation password
/q Quiet installation - no logs to stdout
/v Install Agent in verbose debugging mode.
/disable-ui Prevents the installation of the Agent UI.
/path Set custom installation path for the Agent program files.

/data-path Set custom installation path for the Agent data files (certificates, log files,
configuration and storage).
/logging-profile Set the logging rotation profile for the Agent ('min', 'max' or 'medium').
/labels list of labels in the form of key1:value1,key2:value2 for labeling the agent
instance
/installation-profile ● Install agent modules from specific profile
Expected Result
The following lines should appear in the installation script output when the installation is
completed successfully:
The Guardicore Agent Service service was started successfully.

Installing Agent UI
Installation completed 2020-02-10 07:56:05.768 UTC
Removing temporary installer files
Exiting installer 2020-02-10 07:56:05.768 UTC
Possible Installation Errors

1. No Aggregator connectivity - the following error will be shown in the end of the
installation script output when there is no connectivity from the server to the aggregator:
Wget returned error #1. Aborted.
2. Wrong installation password - the following error will be shown in the end of the
installation script output when a wrong agent installation password is used:
Installation aborted due to authentication error while
downloading package, check if the password is correct.
3. The script was run with low privileges - an administrative password prompt will be shown
in case the script is run with low privileges.

Windows Agents - Offline Installation
Installation Script
1. Fetch the Windows installer exe from the Guardicore technical platform owner (to be
either downloaded from the Management server internal repo, or from the Guardicore
customer portal).
2. Copy the installer to the target server with name GuardicoreAgentSetup.exe
3. Open the Windows command prompt with administrative privileges and run the installer
with a minimal set of 5 parameters as follows:
GuardicoreAgentSetup.exe /q /offline /a <aggregator_FQDN> /p
"<agent_installation_passphrase>"
Note: Before running a programmatic offline installation, it is recommended to validate that the
latest version of the Agent is not already installed. To do so, query the content of the registry key
HKLM\SOFTWARE\GuardiCore\Version and compare it to the version of the Agent that is
about to be installed.
Expected Result
The Guardicore Agent Service service was started successfully.
Installing Agent UI
Installation completed 2020-02-10 07:56:05.768 UTC
Removing temporary installer files
Exiting installer 2020-02-10 07:56:05.768 UTC
For offline installations, the installation output can be found at

%TEMP%\Guardicore-Installation\installer.log

Windows Agent - Dependency Packages

The Agent installation process involves the following additional packages:
1. Microsoft .net framework 3.5:
a. On Windows server 2008 or 2008R2, if .NET 3.5 is not yet enabled, the Guardicore
installer will enable it.
b. On Windows server 2003 and older or Windows server 2012 and newer
Guardicore installer does not impact any existing .NET settings.
c. On Windows Desktop operating system Guardicore installer does not impact any
existing .NET settings.
Note - .NET 3.5 is always included in the OS. Guardicore does not install it, but only
enables it.
2. On Windows server 2003 and older, the Guardicore installer installs a Windows
dependency called KMDF. KMDF will not be installed on any OS newer than Windows
Server 2003.
Windows Agent - Post Installation Validation and Troubleshooting

The following commands can be run for validation a few minutes after installation has completed:
C:\Program Files\Guardicore\gc-agents-service.exe --ctrl list-services
Expected result when the Aggregator is accessible and the Agent is successfully installed:
* Service reveal-channel [Up]
* Service reveal [Up]
* Service enforcement-channel [Up]
* Service enforcement [Up]
* Service controller [Up]

The Agent should now appear in the Guardicore Centra UI (in the Administration/Agents
screen), and can now be managed centrally.
Expected result when the Aggregator is not accessible, but the Agent is successfully installed:
* Service reveal-channel [Down]
* Service reveal [Up]
* Service enforcement-channel [Down]
* Service enforcement [Up]
* Service controller [Up]
In case of a different result, the following common troubleshooting steps are recommended:
1. To validate that Agent service is installed and running, run:
sc query "GC-AGENTS-SERVICE"
Expected result:
SERVICE_NAME: GC-AGENTS-SERVICE
TYPE : 10 WIN32_OWN_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE,
ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
1. To validate the Agent is connected to the right Aggregator, the following line should appear
in the log file
C:\ProgramData\Guardicore\logs\gc-controller.log:
2019-06-04 2019-06-04 11:18:36,588979 [2168:MESSAGE] [channel]

TLS handshake to <aggregator fqdn>:443 completed
When the Aggregator is not accessible, the following line will appear:
2019-06-04 11:38:23,278749 [3068:MESSAGE] [channel] resolving
address <aggregator fqdn>:443
Then, 3 lines below the following line will be seen:

2019-06-04 11:38:33,326104 [3068:CRITICAL] [channel] error opening

TCP TLS channel to Aggregator: connection to <aggregator IP>:443 timed
out after 10000ms. Check connectivity and firewall configuration in
between and make sure SSL (TCP 443) is allowed. Contact Guardicore for
further assistance
Note: <aggregator IP> is the IP address that was resolved for <aggregator fqdn>
To validate that the installation password used was correct (once the Agent connects to
the Aggregator), check that certificates were successfully acquired:
The following line should appear at the end of the log file
D:\ProgramData\Guardicore\logs\gc-cert-client.log:
2019-05-30 11:45:32,467260 [3900:MESSAGE] [crt-client] certificate

have been enrolled successfully
When the Agent installation passphrase is incorrect, the following line should appear in the
log file:
2019-05-30 11:52:17,249135 [396:CRITICAL] [crt-client] failed to

get CA certificate
2. To validate that the Agents version is correct, run:

"C:\Program Files\Guardicore\gc-agents-service.exe" -V
The following line should appear in the result:

Guardicore agents service <AGENT VERSION>
Alternatively, the registry key HKLM\SOFTWARE\GuardiCore\Version contains the Agent
version.
Windows Agent Uninstall

The Agent can be uninstalled using Add or Remove Programs.
Alternatively, uninstall the Agent by running the the following command as administrator:
msiexec /quiet /X{EF2986BA-CE63-44BF-B040-9540AC91E187}

Windows Agent Upgrade

Upgrading the Agent is done by re-running the installation process as described above. The
installation process will uninstall the old Agent version and install the new version.
In case the latest version of the Agent is already installed, re-running the installation process will
uninstall the agent and re-install agent again.
Windows Agent Directory Structure

Directory Description
C:\Program Files\Guardicore Agent binaries
C:\ProgramData\Guardicore\certs Agent certificates
C:\ProgramData\Guardicore\config Agent configuration files and policy
C:\ProgramData\Guardicore\logs Agent logs
C:\ProgramData\Guardicore\persistent-config Agent DNS cache
It is possible to modify the binaries and configuration paths - see Customization Options.

3.5.2 Windows Agent Deployment via PowerShell
Requirements:
● Windows 2008 and above with minimum Powershell version 3.0
● Centra v31 and above.
● Active WinRM service at the endpoints.
Preparation/Prerequisites
Run script with high privileges user (such as domain admin).
You’ll be prompted to enter user credentials.
Place “nodes.txt” in the same directory of the script or provide a path to endpoints file location in
txt format (supported only when running from command line). This file should contain a list of the
nodes you wish to install the agents on. Can use hostnames or IPs.
Tip/ Important Note-
If endpoints are members of different domains and there is no trust between the domains,
consider to separate the script run and each time use the current domain admin’s credentials
Instructions and Steps

Arguments
Script can be run from the command line or from ISE. Pass the following variables as
arguments in the following order:
1. (Mandatory) Aggregator cluster’s FQDN or IP.
In ISE- will ask as variable: “FQDN_addr”
2. (Mandatory) Installation Password (available from UI console).
In ISE- will ask for variable: “Installation_Password”
3. (Mandatory) Installation profile flag. Enter default for default profile
In ISE- will ask for variable: “Installation_Profile”
4. (Optional) [-path] Path to endpoints file location.
5. (Optional) [-sleeptime] Time to wait for the remote installation to finish before
closing the remote session per each node. Currently- Should Not Use.

Execution:
● Examples when running from command line:
.\Agent Deployment.ps1 FQDN.com PASS default
.\Agent Deployment.ps1 FQDN.com PASS default -path C:\endpoints.txt
● When running from Powershell ISE:

Script will ask for mandatory parameters and nodes file must be located in the
script’s directory (nodes.txt).
Actions:
The script will perform the following actions:
1. Provide a ping test to all servers from the endpoints file and print the results to the
console.
2. Connect to each machine and do the following:
● Download the agent installation package from the Aggregators Cluster.
● Install the agent and wait for the installation to finish.
● Check and print whether installation passes successfully or fails. For failed
nodes’ installations, logs are retrieved from the endpoints remotely and
placed under “Endpoints Logs” directory which will be created in the script
directory. Retrieval of installation logs are done by using SMB
administrative share, thus please make sure that firewall(/local firewall)
doesn’t block this connection.
● Provide Agent’s services status for successful installations.
3. The script writes the records of all run operations within a log file called:
“gc_windows_agents_deployer.log“
and will be located in the same directory that the script was executed from.

Script File for Download

Refer to the following link in Zendesk to download the deployment script:
https://guardicore.zendesk.com/hc/en-us/articles/360021483199-Windows-Agent-Deployment-
via-PowerShell

3.6 Linux Agents Installation
Note: The following instructions apply for CentoOS based flavors - CentOS, RHEL, OracleLinux
SUSE, Amazon Linux etc. Contact Guardicore for Ubuntu or Debian instructions.
Linux Agents - Online Installation
Installation Script
This is the template of the Agent installation script that should be run with a user that has sudo
permissions:
export UI_UM_PASSWORD='<agent_installation_passphrase>'
export GC_PROFILE='default'
wget https://<aggregator_FQDN>/guardicore-cas-chain-file.pem
--no-check-certificate -O /tmp/guardicore_cas_chain_file.pem
# expected checksum <certificate checksum>
SHA256SUM_VALUE=`sha256sum /tmp/guardicore_cas_chain_file.pem | awk '{print
$1;}'`
export INSTALLATION_CMD='wget --ca-certificate
/tmp/guardicore_cas_chain_file.pem -O- https://<aggregator_FQDN> | sudo -E
bash'
if [ $SHA256SUM_VALUE == <certificate checksum> ]; then eval
$INSTALLATION_CMD; else echo "Certificate checksum mismatch error"; fi
Parameters
GC_PROFILE=default Install Agent modules from specific profile
<aggregator_FQDN> The Aggregator address aggregator_FQDN is to be

provided by the Guardicore Technical platform owner
<agent_installation_passphrase> The Agent installation passphrase is retrieved from the

Guardicore Centra UI:
Administration → System → Configuration → Agents
installation → Agents installation password

<certificate checksum> The certificate checksum is retrieved as follows:
1. In the management UI, open Administration ->

Agents -> Agent Installation Instructions.
2. Locate “Linux Red Hat 6.2+”.
3. Click Select Aggregator Server and choose an

Aggregator.
A script appears displaying the expected certificate

checksum value.
Expected Result
Mon Feb 10 09:29:17 IST 2020 [*] Successfully downloaded reveal kernel modules
...
Mon Feb 10 09:29:17 IST 2020 [*] Successfully downloaded enforcement kernel modules
...
Mon Feb 10 09:29:18 IST 2020 [*] Package installation done!
...
Mon Feb 10 09:29:19 IST 2020 [*] Guardicore agent installed successfully
Possible Installation Errors

No Aggregator connectivity - curl errors will be shown when there is no connectivity from the
server to the Aggregator
Wrong installation password - the following error will be shown at the end of the installation
script output when a wrong Agent installation password is used:
Mon Feb 10 08:16:41 IST 2020 [*] 'curl' command failed health-check and connectivity
test to aggregator, probably wrong password (12345678)
Mon Feb 10 08:16:41 IST 2020 [*] Deleting temporary CA file:
/tmp/guardicore_cas_chain_file.pem
Mon Feb 10 08:16:41 IST 2020 [*] Installation failed
Wrong certificate checksum - the following error will be shown in the end of the installation script
output when a wrong certificate checksum is used:

Certificate checksum mismatch error
The script was run with low privileges - the following error will be shown in the end of the
installation script output when the script is run with low privileges:
tee: /tmp/gc-agent-installation.log: Permission denied
tee: /tmp/gc-agent-installation.log: Permission denied
Mon Feb 10 09:25:39 IST 2020 [*] Not running as root (Installation must be
executed from root user)

Unsupported OS version - the following error will be shown in the end of the installation script
output when the script runs on an unsupported OS version:
Mon Feb 10 08:53:57 IST 2020 [*] Checking agents support for this machine
Mon Feb 10 08:53:57 IST 2020 [*] Guardicore agent support for <OS
version name> is missing: Package not found
Mon Feb 10 08:53:57 IST 2020 [*] Contact Guardicore at
support@guardicore.com for more information
Mon Feb 10 08:53:57 IST 2020 [*] Uploading log file (32493 bytes) to server on
172.16.8.1:443
Mon Feb 10 08:53:57 IST 2020 [*] End of installation procedure (status:
no_ga_pkg_support)
Contact Guardicore support to get Agent support for the necessary OS version.
Unsupported kernel version - the following error will be shown in the end of the installation script
output when the script runs on an unsupported Linux kernel version:
Mon Feb 10 09:02:51 IST 2020 [*] Failed to download reveal kernel modules
...
Mon Feb 10 09:02:51 IST 2020 [*] Failed to download enforcement kernel modules

Integrate the Management instance with the Guardicore KO SaaS, or contact Guardicore support
to acquire kernel modules for the necessary kernel modules (this usually takes up to two days).
Note that the installation is to be considered as completed successfully, as the KO module can be
published to the Agent remotely.
Linux Agents - Offline Installation
Installation Script
1. Fetch the Agent installation package RPM from the Guardicore technical platform owner
(to be either downloaded from the Management server internal repo, or from the
Guardicore customer portal).
2. Copy the RPM to the target server /tmp/<package_name>.rpm
3. In case an old Agent is already installed on server, remove the Agent and log files in
advance to reduce the footprint on the server:
gc-agent uninstall
rm -f /var/log/gc-*log*
Note: this step is not required in Online installation.
4. Execute:
export IS_OFFLINE_PACKAGE=true
export UI_UM_PASSWORD='<agent installation passphrase>'
export SSL_SERVER="<aggregator fqdn>"
<rpm/deb> -i /tmp/<package_name>
# RHEL 6 and higher

rpm -i ./<package_name_for_rhel6+>.rpm
# RHEL 4-5
rpm -i ./<package_name_for_rhel4-5>.rpm
Advanced installation parameters

To customize Agent installation for Linux use these environment variables before launching the
RPM:

Variable Description
export IS_OFFLINE_PACKAGE=true Sets the installation to offline mode
export SSL_SERVER="FQDN or IP" Aggregator address. agregator_FQDN is to be

provided by the Guardicore Technical platform owner
export UI_UM_PASSWORD="<password>" Agent installation passphrase. retrieve from the

Guardicore UI: Administration → System →
Configuration → Agents installation → Agents
export DAEMON_ARGS="--verbose" Install Agent in verbose debugging mode.
export install the agent and logs in a custom path instead of

CUSTOM_GC_ROOT=<custom_path> /var/lib/guardicore.
Using this option, --prefix <custom_path>
parameter should be added to the rpm command
export GC_LOGGING_PROFILE=min Set the logging rotation profile for the Agent ('min',
'max' or 'medium').
export GC_USER=<username> Override default username value used for the

Guardicore agent
export GC_CONTAINER_MODE=native Enable native docker support
export GC_PROFILE=default Install Agent modules from specific profile
Linux Agents - Post Installation Validation and Troubleshooting

The following commands can be run for validation few minutes after installation completed:
gc-agent status
Expected result when Aggregator is accessible and Agent is successfully installed:

* Service 'reveal' [Up]:
* Service 'reveal-channel' [Up]:
* Service 'enforcement' [Up]:
* Service 'enforcement-channel' [Up]:

* Service 'controller' [Up]:
The Agent should now appear In the Guardicore Centra UI (Administration/Agents), and can be
managed centrally.
Expected result when the Aggregator is not accessible but the Agent is successfully installed:
* Service 'reveal' [Up]:
* Service 'reveal-channel' [Down]:
* Service 'enforcement' [Up]:
* Service 'enforcement-channel' [Down]:
* Service 'controller' [Up]:
In case of a different result, the following common troubleshooting steps are recommended -
1. To validate that the Agent is connected to the right Aggregator, run the following:
gc-agent system-status
This is the result when the Aggregator is accessible and the password is correct:
[*] Guardicore Aggregation server: <aggregator fqdn>:443

[*] Guardicore Aggregation server access: OK
When the Aggregator is not accessible, this is the expected output:
[*] Guardicore Aggregation server: <aggregator fqdn>:443

[-] Guardicore Aggregation server access: Down
2. To validate that the installation password that was used was correct (once the Agent
connects to the Aggregator), check that certificates were successfully acquired:
The following line should appear in the log file /var/log/gc-cert-client.log:
2019-05-30 13:08:27,874304 [21481:MESSAGE] [crt-client]

certificate have been enrolled successfully
When the Agent installation passphrase is incorrect, the following line should appear in the
log file /var/log/gc-cert-client.log:

2019-05-30 13:41:30,774465 [30225:CRITICAL] [crt-client]

failed to get CA certificate
3. To validate that the Agent’s version is correct, run the following:
gc-agent version
The following line should appear in the result:
Guardicore agents service <AGENT VERSION>
Validation of kernel version - once the Agent is connected to the Guardicore Aggregator, the
Guardicore technical platform owner will validate that the Agent successfully fetched the
required KO (kernel object) module. The Guardicore UI enables this validation, as well as proactive
search of the supported Kernel versions.
In case of a missing KO - integrate the Management instance with the Guardicore KO SaaS, or
contact Guardicore support to acquire kernel modules for the necessary kernel modules (this
usually takes up to 2 days). Note that the installation is considered as completed successfully, as
the KO module can be published to the Agent remotely.
Linux Agents Uninstall

The following command needs to be run as root:
gc-agent uninstall
Linux Agent Upgrade

Upgrading an Agent that was installed via online installation is done by re running the installation
process as described above. The online installation process will uninstall the old Agent version and
install the new version.
In case the latest version of the Agent is already installed, re running the installation process will
only perform Agent certificates re enrollment. This will not cause an Agent restart and will take
effect only after restarting the Agent.

For Agents installed in offline installation, it is required to uninstall the Agent and then re-run the
offline installation process as described above.
Linux Agents Directory Structure

/var/lib/guardicore/storage/tls Agent DNS cache
/var/lib/guardicore/storage/persistent-config Agent configuration files
/var/lib/guardicore/storage/config Agent configuration files
/var/lib/guardicore/sbin Agent binaries
/var/log/gc-*.log Agent logs
/var/lib/guardicore/bash_completion.d Agent commands bash completion configuration
/var/lib/guardicore/bin Agent binaries
/var/lib/guardicore/labels.d Agent scripts
/var/lib/guardicore/services.d Agent scripts
/var/lib/guardicore/run Agent IPC sockets
/var/lib/guardicore/modules Agent kernel modules
/etc/default/guardicore Agent configuration file
/sys/fs/cgroup/*/guardicore Agent cgroups resource limitation configurations
/etc/bash_completion.d/guardicore* Agent commands bash completion configuration
/etc/rc.d/init.d/gc-agent Agent startup script
/usr/bin/gc-config Agent configurations control script
/usr/bin/gc-agent Agent control script

It is possible to modify the binaries and configuration paths - see Customization Options.

3.7 AIX Agent Installation

Supported AIX OS Versions
The following AIX OS versions are supported:
● AIX 6.1
● AIX 7.1
● AIX 7.2
AIX Agent Installation Prerequisites

Agent installation on an AIX operation system requires the following prerequisites:
1. Root permissions to install the AIX package.
2. POSIX compatible tools (sed, grep, etc).
3. bash version 4.2 or newer
a. Validate using bash --version
4. For Agent installation using Online installation script, wget version 1.9.1 or newer located
in /usr/bin/wget is required
a. Validate wget location by running which wget
b. Validate wget version by running wget --version
5. It is required to have IP Filtering (IPF) version 4.1.13 or newer installed. See IPFilter below
for more information.
a. Validate using ipf -V
b. If IPF is not installed on the server, the Agent installer will fetch and install an
installation package for IPF version 4.1.13.
Note: Agent uninstallation does not remove the installed IPF package. It should be
removed manually.
You can use this link to download GNU and open source tools for AIX.

Configuring the Enforcement Mechanism: IPFilter

The Enforcement module of the Guardicore Agent for AIX relies on IP Filter (IPF), which is the OS
native firewall utility for the AIX OS.
By default, IPF loads persistent configuration into memory, typically from the file
/etc/ipf.conf. As the Agent starts and receives the latest policy from Centra, the Agent
converts the policy to IPF rules and overrides the existing IPF rules in memory, thus enforcing only
the rules received from Centra policy.
Previously existing persistent IPF configuration (/etc/ipf.conf) is not overridden by this

process, and will be re-applied by the OS in the next system restart, or manually by the user.
You can dump your current IPF configuration to the persistent IPF configuration file by running
the following command:
ipfstat -io > /etc/ipf.conf
It is highly recommended to make sure that all the rules are being saved in the persistent
configuration file.
After Agent uninstallation, run the following command to remove existing rules and load the
previous IPF configuration: ipf -Fa -f /etc/ipf.conf
IPFilter Installation
The Agent installation procedure attempts to install an IPFilter package (version 4.1.13), if there is
no IPFilter package installed on the server. The package will not be removed in case of Agent
uninstallation. You can also download and install the IPFilter package manually by downloading
the package from IBM repository.
Use the following command to install the package:

installp -Y -aX -d<ipf_fileset_file> ipfl
Enable the package using the following command:
/usr/lib/methods/cfg_ipf -l

AIX Installation and Uninstall

After the installation of the AIX Agent, all Guardicore processes will automatically start and no
server reboot is required. A start/stop script is automatically created (/etc/init.d/gc-agent) so all
Guardicore processes are persistent upon reboot.
If the Agent is uninstalled all processes are stopped and the start/stop script (/etc/init.d/gc-agent)
will also be removed.
Online installation using wget

The following instructions install an Agent against an Aggregator (replace <Password> and
<Aggregator_IP_OR_FQDN> with relevant data):
wget https://<Aggregator_IP_OR_FQDN>/guardicore-cas-chain-file.pem
--sslcheckcert=0
# expected checksum {certificate checksum}
SHA256SUM_VALUE=òpenssl dgst -sha256 /tmp/guardicore_cas_chain_file.pem |
awk '{print $2}'`
export INSTALLATION_CMD='wget --sslcafile=/tmp/guardicore_cas_chain_file.pem
-O- https://{Aggregator_IP_OR_FQDN} | bash'
if [ $SHA256SUM_VALUE == {certificate checksum} ]; then eval
$INSTALLATION_CMD; else echo "{sha256_mismatch}"; fi
The instructions can be found also in the Agent Installation Instructions page in the Centra UI.
Note - The Aggregator has to be accessible for the installation to succeed.
AIX Upgrade
The usual upgrade procedure is to uninstall and then re-install the Agent. To uninstall the Agent
see the following section.

Offline Installation Parameters
<Aggregator_IP_OR_ Aggregator address. Aggregator_IP_OR_FQDN is to be provided by the

FQDN>
Guardicore Technical platform owner
<agent_installatio Agent installation passphrase. retrieve from the Guardicore UI:

n_passphrase> Administration → System → Configuration → Agents installation →
Agents installation password
<certificate 1. In the management UI, open Administration -> Agents -> Agent
checksum>
Installation Instructions.
2. Look for “AIX”.
3. Click the Select Aggregator Server button and choose one of
the Aggregators.
A script will appear that shows the expected certificate
checksum value.
Advanced Offline Installation Parameters

RPM:

export SSL_ADDRESS="FQDN or IP" Aggregator address. agregator_FQDN is to be

provided by the Guardicore Technical platform
owner
export GC_LOGGING_PROFILE=medium Set the logging rotation profile for the Agent ('min',
'max' or 'medium').
This profile cannot be changed after the
installation. (Default is medium)

export GC_PROFILE=default Install agent modules from specific profile
Uninstall
In order to uninstall the Agent, run the command gc-agent uninstall.
The following files are left on the server after uninstallation:
File Description
/var/lib/guardicore/storage/install_date Agent installation date marker
/var/lib/guardicore/storage/config Agent modules configuration files
/etc/default/guardicore.rpmsave Agent Configuration files
IP Filter Package
AIX Agent Files Location

/var/lib/guardicore Agent binaries

3.8 Solaris Agent Installation

Supported Solaris OS Sub-Versions
The following Solaris OS versions are supported:
● Solaris 10 SPARCv9, minor version U10 or newer
● Solaris 10 x86_64, minor version U8 or newer
● Solaris 11.1-11.4 SPARCv9
● Solaris 11.1-11.4 x86_64
Solaris Agent Prerequisites

Agent installation on Solaris operation system requires the following prerequisites:
1. POSIX compatible tools (sed, grep, etc) under the directory /usr/xpg4/bin/
2. bash version 3.2 or newer
a. Validate using bash --version
3. For Agent installation using the Online Installation Script, wget version 1.12 or newer
located in /usr/sfw/bin/wget is required.
a. Validate wget location by running which wget
b. Validate wget version by running wget --version
Note - if this requirement is missing, install the agent using online installation using local
files.
4. On Solaris version version 11.3 and below, it is required to have IP Filtering (IPF) version
4.1.9 or newer installed. See IPFilter below for more information.
a. Validate using ipf -V

5. On Solaris 11.4, Packet Filter (PF) firewall should be installed but disabled. See Packet
Filter below for more information.
a. Disable PF using pfctl -d
Note - This is required for having the Enforcement module of the agent installed and running.
Installing the Agent with the Enforcement modules disabled allows agent installation without
disabling PF.
Configuring the Enforcement Mechanism: IPFilter
Solaris 11.3 and below - IPFilter

The Enforcement module of the Guardicore Agent for Solaris up until version 11.3 relies on IP
Filter (IPF), which is the OS native firewall utility for these versions.
By default, IPF loads persistent configuration into memory, typically from the file
/etc/ipf/ipf.conf. As the Agent starts and receives the latest policy from Centra, the Agent
converts the policy to IPF rules and overrides the existing IPF rules in memory, thus enforcing only
the rules received from Centra policy.
Previously existing persistent IPF configuration (/etc/ipf/ipf.conf) is not overridden by this

process, and will be re-applied by the OS once the Guardicore agent is uninstalled.
Solaris 11.4 - Packet Filter

Solaris 11.4 no longer uses IPF as its firewall utility, but Packet Filter (PF) firewall instead. The
Enforcement module of the Agent on Solaris 11.4 relies on PF as its enforcement mechanism.
The Centra policy rules are loaded into memory by the Agent similarly to IPF to enforce the policy
configured in Centra. However, because PF handles also the server’s NAT configuration, and
because this process overrides all PF rules, NAT rules will be overridden as well. Therefore, the PF
firewall must be disabled before installing Solaris Agents for Solaris 11.4:

● If the firewall is not disabled, the installation will stop and the following message is
displayed: “Solaris Firewall is enabled, disable firewall to install enforcement agent”
● To disable the firewall, use the command pfctl -d or run

export GC_SOLARIS_OVERWRITE_PF=yes before installation.
● To bypass this requirement, see Installing the Agent with the Enforcement Modules
disabled.
Agents Deployed on Solaris Zones

Installing a Guardicore Agent on Solaris with a Solaris Zones configuration is supported with the
considerations that are explained in this section. Solaris Zones can be configured in different
ways:
● Shared-IP Global Zone
● Shared-IP Non-Global Zone
● Exclusive-IP Non-Global Zone
Agent installation and functionality varies according to the configuration of the Solaris Zone:
Global Zone
An Agent can run on a global zone with shared IP to provide L7 visibility and L4 enforcement for
the global zone and L4 visibility and enforcement for all it’s shared-ip non-global zones. In this
case, the global zone and all its shared-ip non-global zones will be treated as a single entity
("Asset") in the system.
Shared-IP Non-Global Zone
A shared-IP zone is a non-global zone that shares the IP state and configurations with the global
zone. In this configuration, it is not possible to install the Agent inside the shared-ip zone because
it cannot run the native Solaris IP Filtering (IPF) module, which belongs to the global zone only.
Shared-IP Non-Global Zones will therefore be treated as a single entity with their Global zone - in
case the Global zone has an Agent installed, L4 visibility and L4 enforcement will be enabled also
for its Shared-IP zones.

Exclusive-IP Non-Global Zone

An exclusive-IP zone has its own IP-related state. This configuration enables installing an Agent on
each zone of this type and treating it as a unique entity in Centra (Asset). L7 Visibility and L4
Enforcement will be supported for this type of non-global zone by installing an Agent in each
non-global zone. The Agent cannot be installed in a global zone in this configuration.
Global Zone with NAT Configurations
Agent installation is not supported when the Global zone has NAT configurations.
Installation and Uninstall
Online installation using wget

The following instructions install an Agent against an Aggregator (replace <Password> and
<Aggregator_IP_OR_FQDN> with relevant data):
/usr/sfw/bin/wget
https://<Aggregator_IP_OR_FQDN>/guardicore-cas-chain-file.pem
/usr/sfw/bin/wget --no-check-certificate https://<Aggregator_IP_OR_FQDN> -O-
| bash
The instructions can be found also in the Agent Installation Instructions page in Centra UI.
Installation Parameters using wget
<Aggregator_IP_OR_ Aggregator address. Aggregator_IP_OR_FQDN is to be provided by the

FQDN>
Guardicore Technical platform owner
<agent_installatio Agent installation passphrase. retrieve from the Guardicore UI:

n_passphrase> Administration → System → Configuration → Agents installation →
Agents installation password


Advanced Installation Parameters using wget
RPM:

export SSL_ADDRESS="FQDN or IP" Aggregator address. agregator_FQDN is to be

provided by the Guardicore Technical platform
owner
export GC_LOGGING_PROFILE=medium Set the logging rotation profile for the Agent ('min',
'max' or 'medium').
This profile cannot be changed after the
installation. (Default is medium)
export GC_PROFILE=default Install agent modules from specific profile
Online Solaris Agent Installation Using local Files

The following installation instructions allows bypassing the requirement for wget by copying the
installation files locally. The instructions are separated into preparations required to do only once
(until a system upgrade is performed) and to instructions to be ran on every Solaris server for
Agent installation:
One time preparations:

1. From a server with accessibility to the Aggregator and curl installed, download the Agent
installation script:
curl -s -k -o solaris_installation.sh https://<Aggregator_IP>

2. From a server with accessibility to the Aggregator and curl installed, download the
Aggregator certificate chain:
curl -s -k -o guardicore_cas_chain_file.pem
https://<Aggregator_IP>/guardicore-cas-chain-file.pem
3. Download Solaris x86_64 and SPARCv9 agent packages from the Guardicore customer
portal. You should download the following two files:
a. gc-guest-agent-polling-sunos-sparcv9.pkg.gz
b. gc-guest-agent-polling-sunos-x86_64.pkg.gz
On the Solaris server:

1. Upload the installation script solaris_installation.sh to the server.
2. Upload the Aggregator certificate chain guardicore-cas-chain-file.pem to the server to the

path /tmp/guardicore-cas-chain-file.pem
3. Depending on the CPU architecture of the Solaris server, upload one of the agent
installation packages. Run isainfo -k to decide which package to upload in the
following way:
a. If the result of the command is sparcv9, upload the package

gc-guest-agent-polling-sunos-sparcv9.pkg.gz
b. If the result of the command is amd64, upload the package

gc-guest-agent-polling-sunos-x86_64.pkg.gz
4. Unzip the installation package:

gunzip <agent_installation_package>.pkg.gz
An uncompressed Agent installation package should be extracted, with .pkg file type.
5. Run
Export GC_SOLARIS_INSTALL_PKG_FILE=<agent_installation_package>.pkg
6. Run solaris_installation.sh
Note - The Aggregator has to be accessible in order for the installation to succeed

Installing an Agent with enforcement module disabled on Solaris 11.4

Disabling PF is a requirement for a full agent installation on Solaris 11.4. In case disabling the PF if
not possible or not desired, it is possible to install the agent with the enforcement module
disabled, allowing visibility collection and reputation analysis but not policy enforcement.
To do so, supply the following environment variable before running the installation process on the
Solaris 11.4 server:
export DISABLE_ENFORCEMENT="true"
Uninstall
In order to uninstall the Agent run the command gc-agent uninstall, and reply yes twice to
the questions Do you want to remove this package? that are prompted regarding the Agent’s
packages,
The following files are left on the server after uninstallation:
File Description
/var/lib/guardicore/storage/install_date Agent installation date marker
/var/lib/guardicore/storage/tls/guardicore_cas_chain_file.pem Aggregators CA-certificate
Solaris Agent Files Location

/var/lib/guardicore Agent binaries
/etc/default/guardicore Agent Configuration files

/etc/default/guardicore-pkg

Changing these values requires Guardicore to provide a customized package for the customer.
Customizing Agent Installation

The Advanced Options link on the Agent Installation Instruction page provides options for
customizing Agent deployment. This is accomplished by first running Environment variables or
Batch commands with the appropriate flags BEFORE running the Agent deployment script. This is
for experienced users or for those guided by Guardicore.

3.9 Docker Native Agent Configuration

The following article explains how to enable Docker Native in Centra.
Prerequisites
● Install an Agent on each Docker container host machine.
● Run the following commands on each machine:
○ gc-config -s GC_CONTAINER_MODE="native" && gc-agent restart
○ gc-runc-install -install
Setting up Container configuration in Centra

● Go to Centra UI > Administration > System > Configuration > Containers

● Default Grouping
○ The container fields used for grouping in the Reveal mao.
○ Most preferably set to image_name, container_names
● Allowed Docker Label Prefixes
○ The Docker labels who’s connections will be filtered into Centra.
○ Labels that don’t match any of these prefixes will be dropped (separated by new
lines).
● To add Docker Containers into Centra labels- Centra UI > Reveal > Labels
○ Create a label
○ Add a dynamic criteria of your choosing, for example:

3.10 Kubernetes Deployment

Known Issues:
● OpenShift 4 gaps and fixes - refer to GC PS regarding these issues.
● Error in K8S orchestration service when it's set before agent is installed. Service should be
restarted after Agents installed or install Agents before orchestration - refer to GC PS
regarding these issues.
● Limited support for Alerting in Hybrid k8s-agents environments- rules containing k8s
labels have to be intersected with corresponding asset label otherwise it will be derived
throughout the deployment and may result in undesired behavior- refer to GC PS
regarding these issues.
Validate Customer’s K8s Spec Is Supported:

● K8 flavor (Vanilla, AKS, EKS, GKE, OS..)
● Container Runtime
● Node OSs
Prerequisites:
Install a dedicated Aggregator in a dedicated cluster for K8s Agents and

Orchestration.
Firewall Requirements
● Aggregator -> K8s api-server (usually to destination port 6443)
○ Where applicable also: Aggregator -> K8s api authenticator
● K8s api-server -> Aggregator:443
● Every node in the cluster destined to have an Agent installed on -> Aggregator:443

● Every node in the cluster destined to have an Agent installed on -> Guardicore’s GCR - If
using the recommended installation procedure with Guardicore’s GCR to obtain the
docker images.
Aggregator Accessibility Check

● The target Aggregator to manage the Agent and control the orchestration should be
accessible to the K8s API endpoint.
● Running the ‘kubectl cluster-info’ command should provide the API endpoint address (i.e:
https://172.16.200.210:6443).
● If using an Aggregator cluster, make sure to open up traffic for all cluster member IPs. Try
checking that connection works using curl (i.e: 'curl -k https://172.16.200.210:6443')
● Save this info for later use when configuring the Kubernetes Orchestration in Centra.
Additional Files (receive from Guardicore Support)

● docker_registry_auth.json - If using the recommended installation procedure with
Guardicore’s GCR to obtain the docker images (alternatively refer to the custom container
registry support section).
● Relevant KOs packages if not connected to the Guardicore’s KO cloud
Kubernetes Orchestration Configuration

● Guardicore Centra utilizes orchestration in order to collect the workload metadata from
its respective compute engine.
● Whether you are running on VMWare, Azure, AWS or many other compute platforms,
Centra pulls orchestration information from these systems.
● Same in the case of Kubernetes where a reader role to the API is created which allows a
dedicated service in the Centra systems to pull the orchestration information from the
Kubernetes API.
● For OpenShift configuration change kubectl to oc in the commands below.
● For OpenShift 3.11 configuration, please contact Guardicore staff.
Create user and role on the Kubernetes cluster

The following commands need to be run on a machine with admin access to the Kubernetes API:

1. Create a new ‘guardicore-orch’ namespace:

# kubectl create ns guardicore-orch
2. Create a new k8s service account:
# cat <<EOF >>./serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: gc-reader
namespace: guardicore-orch
EOF
# kubectl create -f ./serviceaccount.yaml
3. Create a new cluster role with cluster-wide read privileges:

# cat <<EOF >>./clusterrolereader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gc-cluster-reader
rules:
- apiGroups: [""]
resources:
- events
- nodes
- services
- namespaces
verbs: ["get", "watch", "list"]
- apiGroups: ["apps"]
resources:
- replicasets
- replicasets.apps
- replicasets.apps/scale
- daemonsets
- daemonsets.apps
- deployments
- deployments.apps
- deployments.apps/scale
- nonResourceURLs: ["*"]
EOF
# kubectl create -f ./clusterrolereader.yaml
a. For GKE:

Run the additional step (your_gke_user - guardicore email):

# kubectl create clusterrolebinding gc-cluster-admin-binding --clusterrole=cluster-admin
--user=<your_gke_user>
4. Bind the cluster role ‘cluster-reader’ to the newly created service account:
# cat <<EOF >>./clusterrolereaderbinding.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gc-cluster-reader-role-binding
subjects:
- kind: ServiceAccount
name: gc-reader
namespace: guardicore-orch
roleRef:
kind: ClusterRole
name: gc-cluster-reader
apiGroup: rbac.authorization.k8s.io
EOF
# kubectl create -f ./clusterrolereaderbinding.yaml
5. Get the token associated with the service account and save a copy to use later (note name
of gc-reader-token may differ):
# kubectl get secrets --namespace=guardicore-orch | grep gc-reader
gc-reader-token-lg9tr kubernetes.io/service-account-token 3 3d
# kubectl describe secret gc-reader-token-lg9tr --namespace=guardicore-orch | grep "token:"
token:
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZ
XJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3Bh...ByWg
a. Openshift:
You may receive multiple secret tokens, pick one.
6. Get the decoded cluster certificate and save a copy to use later:
a. Kubernetes:
kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}' |
base64 --decode
b. GKE/EKS:
CA Certificate can be found under Kubernetes -> Clusters -> Show Credentials
c. OpenShift:
Copy the cluster CA certificate.

d. OpenShift 3.11:
oc config view --raw | grep certificate-authority-data | cut -f2- -d: | xargs | base64 -d
Configure Orchestration in Centra
1. Navigate to ‘Datacenter->Orchestrations’ in the administration section.

2. Create new orchestration of 'type' Kubernetes.
3. Provide an orchestration name in the 'Name' field.
4. Select the Aggregator cluster that will service the K8s cluster.
5. ‘Auth host’ - enter the FQDN or IP of the K8/OpenShift API endpoint. The IP can be
obtained by running ‘kubectl cluster-info’. The FQDN or IP should not contain https:// or
http://, only the FQDN or IP itself.
6. ‘Auth port’ - default port for most deployment types is 443 or 6443, but verify this with
your cluster configuration. The port can be obtained by running ‘kubectl cluster-info’.
7. Keep ‘Validate Certificate' unchecked unless providing CA Certificate.
8. ‘Service Account Token’ - Paste the service account token that you copied in the previous
section.
9. CA cert data - Paste the decoded certificate that you copied in the previous section if
‘Validate Certificate’ is checked.
10. Metadata labels - keep checked.
11. Test the connection.
12. Save.

Agent Deployment
The Guardicore components are pushed to the cluster in a dedicated ‘guardicore’ namespace,
including the Agent that is deployed as a Daemonset, as well as the Guardicore webhook for the
admission control process.

A DaemonSet ensures that all (or some) nodes run a copy of a Pod. As nodes are added to the
cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage
collected. Deleting a DaemonSet will clean up the Pods it created.
Please take this into account when planning the Agent deployment that part of the Agent
deployment requires collecting information about all the currently running pods. The deployment
patches all existing K8s controllers as well, injecting a gc-init-container requirement to each of
them, resulting in pod restart.
Also be aware that Guardicore’s Agent runs as a highly privileged pod which inject ko module to
the host.
Agent deployment is possible in 3 ways: Helm based, online, and offline. For all deployment
options the K8s cluster must be able to access the Google container repository (GCR) from each
of the cluster’s nodes in order to pull the Guardicore Agent and webhook images.
*For on-prem with no internet connectivity, it is required to have private and public Container
registries to which we would need to load the Docker Images into or manually load them onto the
nodes.
**Using only a private Container registry without a public Container registry is currently only
supported for ‘Helm’ installation (not ‘Online Installation’).
We strongly recommend installing the Agents using Helm unless there is a good reason not to.
Make sure Helm is installed on the console being used to deploy the agent, where Kubectl is used -
reference.
Make sure to receive a docker_registry_auth.json file from Guardicore Support for

authenticating against Guardicore’s image registries.
Custom Container Registry Support

If the default Guardicore GCR is used skip this step.
If customers can’t access Guardicore’s GCR, using the customer’s Container registries is supported
and requires additional files and configuration of the Management server, please contact
Guardicore support for further instructions.
Container Registries deployed on storage Pods in the same cluster that Guardicore’s agents are
being installed are not supported.

It is important to understand how the Nodes authenticate against the Container Registry, if
each Node is authenticated / each Namespace / each Service Account / other method.
If Helm deployment is to be used, usage of only a private Container registry is supported, in other
installation procedures both private and public registries must be used.
After the images are pushed you may run the preferred deployment method while changing the
Container registry Address/es, if only private registries are used for Helm deployment apply
necessary changes written in Step 4.c.
In order to support it you will first need to download and push the integration images into your
registry:
Image Registry
gc-guest-agent_<version> Private
gc-deployment_<version> Public (or Private in certain use-cases)
gc-admission-webhook_<version> Public (or Private in certain use-cases)
gc-init-container_<version> Public (or Private in certain use-cases)
Use the following commands for both private and public registries:
1. Download the container images from our Customer Portal (contact Guardicore support)
2. Skip the following authentication step when not needed.
Connect to a machine which has a local docker registry and is authenticated with the
customer’s private registry (using the docker login command).
a. For example we run the following in order to login to google registry:
# docker login -u _json_key -p "$(cat gcr_key.json)" https://gcr.io
3. Upload the files downloaded in Step 1 to the machine & verify checksum (SHA256) of files.
4. Load the images files to the machine’s local registry (change image version if needed):
# docker load -i gc-admission-webhook_v5.39.21165.tgz
...
Loaded image: gc-admission-webhook:v5.39.21165
# docker load -i gc-deployment_v5.39.21165.tgz

...
Loaded image: gc-deployment:v5.39.21165
# docker load -i gc-init-container_v5.39.21165.tgz
...
Loaded image: gc-init-container:v5.39.21165
# docker load -i gc-guest-agent_v5.39.21165.2517.tgz
...
Loaded image: gcr.io/guardicore-28070656/gc-guest-agent:v5.39.21165.2517
5. Verify the images are loaded correctly:
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE

gc-deployment v5.39.21165 3aab3f8c630e 2 days ago 45.7MB
gc-admission-webhook v5.39.21165 aa045ee67fee 2 days ago
38.3MB
gc-init-container v5.39.21165 f6a470761e89 2 days ago 37.7MB
gcr.io/guardicore-28070656/gc-guest-agent v5.39.21165.2517 b2d2c930c57d 2
months ago 218MB
6. Tag the loaded images with the customer’s private registry (change <customer-registry):
# docker tag gc-admission-webhook:v5.39.21165 <customer-registry>/gc-admission-webhook:v5.39.21165
# docker tag gc-deployment:v5.39.21165 <customer-registry>/gc-deployment:v5.39.21165
# docker tag gc-init-container:v5.39.21165 <customer-registry>/gc-init-container:v5.39.21165
# docker tag gcr.io/guardicore-28070656/gc-guest-agent:v5.39.21165.2517

<customer-registry>/gc-init-container:v5.39.21165.2517
7. Verify the images are loaded correctly

# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE

gc-deployment v5.39.21165 3aab3f8c630e 2 days ago 45.7MB
<customer-registry>/gc-deployment v5.39.21165 3aab3f8c630e 2 days ago
45.7MB
gc-admission-webhook v5.39.21165 aa045ee67fee 2 days ago
38.3MB
<customer-registry>/gc-admission-webhook v5.39.21165 aa045ee67fee 2
days ago 38.3MB
gc-init-container v5.39.21165 f6a470761e89 2 days ago 37.7MB

<customer-registry>/gc-init-container v5.39.21165 f6a470761e89 2 days ago

37.7MB
gcr.io/guardicore-28070656/gc-guest-agent v5.39.21165.2517 b2d2c930c57d 2
months ago 218MB
<customer-registry>/gc-guest-agent v5.39.21165.2517 b2d2c930c57d 2
months ago 218MB
8. Push the tagged images to customer’s private registry (change <customer-registry> and
image version)
# docker push <customer-registry>/gc-admission-webhook:v5.39.21165
The push refers to repository [<customer-registry>/gc-admission-webhook]
…
v5.39.21165: digest:
sha256:744ab179d89a6a2208e2178c79bd7542e8ec3ae8d728a256a918d8d2e353d1b
1 size: 947
# docker push <customer-registry>/gc-deployment:v5.39.21165

The push refers to repository [<customer-registry>/gc-deployment]
…
v5.39.21165: digest:
sha256:53a1b4fc6209064d096c4ca6aab1670c80407bafbed92cc4ed9d743cbcdc5623
size: 1154
# docker push <customer-registry>/gc-init-container:v5.39.21165

The push refers to repository [<customer-registry>/gc-init-container]
…
v5.39.21165: digest:
sha256:82c9429d64937f61b1a37194beeef583a57c4b7e7baa3ef97acea8a6bba5cd6a
size: 1568
# docker push <customer-registry>/gc-guest-agent:v5.39.21165.2517

The push refers to repository [<customer-registry>/gc-guest-agent]
…
v5.39.21165.2517: digest:
sha256:6b7f513accda13824871f5d293c5db1d8eab535865c3b183ad0a8f4ef6a2a4a9
size: 1575

Helm deployment
Prerequisites:
1. The Helm deployment is supported by Helm v3 (run helm version).

2. Make sure Kubectl has K8 API admin access.
3. On Openshift 3.11 we need to enable the Admission Controller API (it uses an older
version of K8s 1.11 where it was in Alpha version which became production on K8s 1.14).
4. To inspect the Helm chart, locate it on the Management server in the following directory:
var/cache/guardicore/repo/gc-kubernetes-0.1.2.tgz (version ‘0.1.2’ may differ).
5. If a customer cannot access Guardicore’s GCR and needs to use their own Container
registries, please refer to the Custom Container Registry Support section above before
proceeding.
Procedure:
1. In order to deploy the Agent components, go to: ‘Agents>Installation instructions’ in the

administration section.
2. Select ‘AKS’ (the different K8s options run the same commands).
3. Select ‘Helm Installation’.
4. Copy the exports, wget certificate, and helm commands from Centra to the console you
will be running the commands from.
*Remove and do not run the wget to retrieve the docker_registry_auth.json from the
Aggregator.
a. Make sure you received a docker_registry_auth.json file from Guardicore support
and you place it in your working directory.
b. Make sure the SSL_SERVER and SSL_PORT are the Aggregator’s Agent facing IP &
Port.
c. If using the customer’s Container registry:
i. Change the DOCKER_PRIVATE_REGISTRY_ADDRESS and
DOCKER_PUBLIC_REGISTRY_ADDRESS to the customer’s private and
public registries.
If only a private registry, change the
DOCKER_PUBLIC_REGISTRY_ADDRESS to the same private Container
registry (See additional instructions below under Custom Container
Registry Support)

ii.Make sure for authentication against your private registry you use an image
pull secret file named “docker_registry_auth.json” placed in your working
directory.
1. If you are already authenticated, create a file named
“docker_registry_auth.json” containing in it open and closed curly
brackets: {}
5. Run commands.
*Add --debug at the end of your Helm command to get verbose output
6. Validation:
a. # helm list
Should get an object named gc-app
b. # kubectl get all -n guardicore
Should get multiple GC K8s objects
c. Validate Agents in the Centra UI
i. Agents on the cluster nodes in the Agents Page
ii. Pod traffic in Network Log
iii. Pods in the Reveal maps
Online deployment
Prerequisites:
1. For Online Installation, access to Guardicore’s GCR repositories is needed. If a customer If

a cannot access Guardicore’s GCR and needs to use their own private & public registries,
please refer to the Custom Container Registry Support section above before proceeding.
*Using only a private Container registry is not supported for Online Deployment, please
refer to Helm Deployment instead.
2. Make sure Kubectl has K8 API admin access.
Procedure:
1. In order to deploy the Agent components, go to: ‘Agents>Installation instructions’ in the

administration section.
2. Select ‘AKS’ (the different K8s options run the same commands).
3. Select the target Aggregator or Aggregator cluster tasked to handle the K8s cluster and
orchestration in the previous section.
4. Use the default installation profile.

5. Copy the exports, wget certificate, and helm commands from Centra to the console you
will be running the commands from.
*Remove and do not run the wget to retrieve the docker_registry_auth.json from the
Aggregator.
a. Make sure you received a docker_registry_auth.json file from Guardicore support
and you place it in your working directory.
b. Make sure the SSL_SERVER and SSL_PORT are the Aggregator’s Agent facing IP &
Port.
c. If using the customer’s Container registry:
i. Change the DOCKER_PRIVATE_REGISTRY_ADDRESS and
DOCKER_PUBLIC_REGISTRY_ADDRESS to the customer’s private and
public registries.
(See additional instructions below under Custom Container Registry
Support)
ii. Make sure for authentication against your private registry you use an image
pull secret file named “docker_registry_auth.json” placed in your working
directory.
1. If you are already authenticated, create a file named
“docker_registry_auth.json” containing in it open and closed curly
brackets: {}
6. Run the commands.
Offline deployment
1. The difference between the online and offline deployments is that in the offline one the
.tgz file containing the deployment scripts can be manually downloaded and copied, as
opposed to directly downloading it from the Aggregator.
2. The offline option still requires cluster connectivity to the internet in order to download
the Guardicore container image.
3. The offline option allows you to review and edit the YAML files in order to customize the
deployment.

Agent Uninstall Instructions
Helm uninstall
● In order to remove the agent and admission controller webhook run the following
command:
○ helm uninstall gc-app
■ If uninstalling helm fails due to pre-uninstall, run: helm uninstall gc-app
--no-hooks
○ helm repo remove gc-repo
Manual uninstall
1. In order to delete the Guardicore deployment from the cluster manually, use the following
procedure.
2. Make sure you have the deployment .tgz folder available. If not, it can be downloaded again
from the Aggregator as described in the deployment section.
3. Run the “gc_uninstall.sh” command in the folder. It will remove the Guardicore Daemonset,
Admissions webhook and remove orchestration user and permissions.

3.11 Automatic Agent Deployment

Although Agents can be deployed manually as explained in the previous section, to deploy a large
number of Agents it is recommended to make use of the customer’s available provisioning tools.
This section provides instructions on how to use Ansible or SCCM as automatic deployment tools
for efficiently deploying a large number of Agents.
Deploy Agents on Linux servers using Ansible

To deploy Agents on Linux servers with Ansible, follow these steps:
1. Create an Inventory file indicating the servers to which you are deploying Agents. See
https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html for information on
the construction of an Ansible Inventory file.
2. Run the following Ansible playbook snippet:
---
- hosts: all
gather_facts: False
tasks:
- name: Download certificate
get_url:
url: "https://{{ aggr_ip }}/guardicore-cas-chain-file.pem"
dest: /tmp/guardicore_cas_chain_file.pem
validate_certs: no
- name: Install agent

shell: "export CA_FILE_PATH=/tmp/guardicore_cas_chain_file.pem;export

UI_UM_PASSWORD=\"{{ password }}\";wget --ca-certificate
/tmp/guardicore_cas_chain_file.pem -O- https://{{ aggr_ip }} | sudo -E bash"
with the following command:
ansible-playbook install_gc-agent.yml --extra-vars '{"aggr_ip":"AGGREGATOR_IP","password":"PASSWORD"}'
(in the above command, replace AGGREGATOR_IP with the actual IP of the Aggregator, and
PASSWORD with the actual password).
Deploy Agents on Windows Servers Using SCCM
To deploy agents using SCCM follow these steps:
1. Make sure that Guardicore Management and Aggregator Servers are fully
installed and configured.
2. Download the installation script from an Aggregator:
a. Save https://<IP of Agg>/windows_installer.exe
3. Create a reachable network share for the SCCM packages and copy the install.bat to it.
NOTE: Steps 1+2 must be repeated following each Guardicore Centra system patch, before
installing new agents.
4. Create a new Package for Agent installation. Use a Standard Program:
a. Provide a name for the program, such as Guardicore Agents and specify the
following Command line:

windows_installer.exe /a
"<IP1/FQDN1-AGG>:443,<IP2/FQDN2-AGG>:443,<IP3/FQDN3-AGG>:443" /p
<password> /q > c:\windows\temp\agent_installation.log
Note: <password> can be retrieved from UI: Administration → System → Configuration

→ Agents Installation
b. Change the program Run Mode to Run with administrative rights.
c. Change Drive mode to Runs with UNC name.
5. Deploy the packages on the relevant Collection of servers.
Deploy Agents on Windows Servers Using Psexec
To deploy agents using Psexec follow these steps:
1. Download and install psexec from

https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
2. Download the installation script from the following URL:

https://<aggregator_ip>/install.bat
3. Execute the following:
psexec.exe <remote_ip_to_install> -u <user(administrator)> -p

<password> -h -c -f <local_install.bat_path> <guest_agents_password>
Note: psexec can run on several machines from a txt list, with "@list_path.txt" instead of the
<remote_ip_to_install>

3.12 Agent Deployment Verification

Whether manual or automatic deployment was used, it is the administrator’s responsibility to
verify the results of the deployment and make sure that Agents have been correctly installed and
are functioning. The following steps should be followed:
Use the Agent Installation Process Output

The logs of the installation process logs are useful resources for verifying successful Agent
installation or debugging a failed one. The logs are displayed on the screen during the Agent
installation process, and are a good indication of the success of the installation. In case of a failed
installation, share this output with Guardicore’s support.
Use the Agent Screen to View the List of Installed Agents

The Agent screen in the Administration UI (Components/Agents) provides a variety of features
that enable quickly checking Agents and discovering those that have problems:

The Modules column displays the status of Agent modules. Modules that are installed appear as
blue icons. When reviewing the outcome of Agent deployment, use this view to make sure that all
the modules that are expected to be installed really are installed.
Even if modules appear as blue, indicating that they are installed, there may be problems with their
functioning due to the installation or to the limitations of the OS to which they have been installed:
● A red dot (Active with Errors) on a module icon of a newly deployed Agent indicates there
is an error that needs attention. The specific error will be listed as a flag raised for this
agent. For the list of all flags, please refer to Agent Flags.
○ An exception to this is the Polling mode flag on the Reveal module. The Polling
mode flag can sometimes be the expected outcome of a deployment, mostly on
Legacy OSs. In that case, this does not require further attention.
● A yellow dot on a module icon (Active with Partial Capabilities) indicates that the module is
functioning with only partial capabilities. Usually this is expected and caused by OS specific
limitations.
Hovering over the icon displays more information, as in the following figure:

Note that the Enforcement Module icon in the above picture displays a yellow dot; hovering the
mouse cursor over the icon reveals that the Enforcement module has L4 only enforcement. This is
the expected outcome of the Agent deployment on Windows 2003 servers.
The administrator can use a wide variety of filters to quickly check the health of Agent modules.
For example, using the Module limitations filter enables discovering which Agents have L4 only
enforcement as shown in the following figure:
Using the Aggregator filter, the administrator can narrow the list to only those Agents that were
deployed from a particular Aggregator as in the following figure:

Using a combination of filters enables the administrator to quickly review the deployed Agents
and discover those that are not functioning as expected and need additional attention.

3.13 Installing Agent Log Rotation Profiles

For each Agent module, Centra creates and stores log files that record information about the
Agent collected during a session. The information is useful for debugging and includes details such
as failed connection incidents, Agent flags, etc. Depending on the profile that was selected during
installation (see the following section), for each Agent module, a limited amount of storage space is
allocated to each log, and a limited number of logs are stored. When the allocated storage capacity
is reached, the logs are compressed. After compression, if the storage capacity is reached, the
oldest log is deleted.
Available Profiles
During Agent installation, you can choose one of the following three Log Rotation profiles: “min”,
“medium”, “max” for allocating storage space for Agent logs. The “medium” profile is considered to
be the default profile.
The type of profile determines the amount of debugging information that is collected and the time
span over which it is collected. The Min profile collects the least amount of information, while the
Max collects the most. Thus, the choice of profile may affect troubleshooting.
The following table describes the estimated storage required for each Log Rotation Profile:
Min Medium (default) Max
90 MB 220 MB 700 MB
For more detailed information on Log Rotation Profiles, see the Administration Guide.
Installation Configuration for Agent Log Rotation

To set the Agent Log Rotation profile during Agent installation use the following instructions.

Installation for Agent Log Rotation on Windows

Use the /logging-profile installation parameter with the desired profile.
Example: windows_installer.exe /q /a 172.16.100.50 /p <password> /logging-profile min
Installation for Agent Log Rotation on Linux/Solaris/AIX
Use the following environment variable during installation:
export GC_LOGGING_PROFILE=min

4 Additional Deployment Options
4.1 Orchestrations
4.1.1 VMware Orchestration configuration (vCenter integration)
As mentioned earlier, configuring vCenter Orchestration enables loading VM inventory into

Centra (machine names, status, networks, MACs, etc), giving better context to assets on the
Reveal map and across the whole system. To enable vCenter Orchestration, make sure to establish
a read-only user on vCenter in step 4 above.
The user should be able to read the following objects:
VirtualMachine
GuestNicInfo
GuestIpAddress
HostSystem
HostPortGroup
HostPortGroupPort
DistributedVirtualPort
DistributedVirtualPortgroup
DistributedVirtualSwitch
ComputeResource
VirtualNetwork
Folder

1. Open a Centra supported browser and navigate to https://<Management IP>
2. Log in with the admin user created during Management Server setup wizard. The Centra
Management screen appears.
3. At the upper right of the screen, click the icon to access Administration.
4. Navigate to Data Center > Orchestrations and click to display the

following dialog box:
5. Fill out the dialog box as follows:

For: Type this:

Type vSphere
Name A name of the orchestration
GC Cluster Select Default
user name, password and vCenter IP address Fill in a value for each.
6. Click Save.

4.1.2 AWS Orchestration
Intro
Importing orchestration data helps you label your assets and build policies around them. Centra
enables you to import orchestration data from AWS. Centra's Aggregator connects to the AWS
API to pull metadata on Elastic Compute Cloud (EC2) workloads, VPC flow logs, and more. This
article explains how to configure AWS orchestration.
Preconditions:
Managing AWS Access:
In order to pull metadata from EC2, you must establish authentication between the Aggregator
and AWS. The authentication method depends on the location and permissions of the Aggregator.
There are three ways to establish AWS authentication:
● EC2 IAM Role

● Guardicore Delegate Access
● Customer Credentials
EC2 IAM Role:
This is the recommended implementation if you have an Aggregator running under a VPC that
belongs to the account that you want to monitor.
The role must have a policy attached with all the authorizations required (See AWS Policy
definition)
Guardicore Delegate Access:
This is the recommended implementation if you need to monitor multiple accounts. The assumed
role in these accounts must have a policy attached with all the authorizations required (See AWS
Policy definition).

Customer Credentials:
Only available option if the Aggregator is running outside the AWS environment. The Customer
must create an IAM user with programmatic access only (Access/Secret Key). It does not require
console access. The user must have a policy attached with all the authorizations required (See
AWS Policy definition)
AWS Policy definition:
In order to authorize the queries that the orchestrator makes you need to create a Custom policy
or use a predefined AWS Policy.
AWS provides a read only policy “AmazonEC2ReadOnlyAccess” that has a superset of the
required permissions.
If you want to create a customer policy with the minimal required authorization, you can use the
following JSON definition:
"Version": "2012-10-17",
"Statement": [
"Sid": "Orchestrator",
"Effect": "Allow",
"Action": [
"ec2:DescribeVpcs",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",

"ec2:DescribeRegions",
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeAvailabilityZones"
],
"Resource": "*"
Starting AWS Orchestration Configuration:

To start configuring AWS orchestration:
1. In the Administration panel, select Data Center/Orchestrations and click the Add
Orchestrations button . The Add New Orchestration dialog box appears.
2. In the Type field, select AWS, and in the following fields, type a name for the orchestration
and select a GC cluster.
Configuring AWS Authentication:
The administrator uses the following section of the Add New Orchestration dialog box to
configure AWS authentication as explained in the sections below:

Configuring EC2 IAM Role Authentication:
1. Verify that an AWS IAM role has been created. For instructions on how to create an AWS
IAM role, see the section at the end of this article, or refer to AWS documentation.
2. In the authentication method field, select EC2 IAM Role. There is no need to fill out any
other Authentication fields and you can proceed to the region name field.
Note: If you want to assume a different role, use the role arn field to type a new Amazon Resource
Name (ARN) of the role to assume.

Configuring Guardicore Delegate Access Authentication:

Guardicore Delegate Access is configured by Guardicore Support. To configure authentication, the
customer must supply the external id and the arn role to Guardicore Support.
Configuring Customer Credentials Authentication:

1. In the authentication method field, select Customer Credentials.
2. In the access key id field, provide an AWS access key id.
3. In the secret access key field, provide an AWS account secret access key id.
4. Proceed to the region name field.
Creating an AWS IAM role:

For an explanation of AWS IAM role see What is IAM?
Following are instructions for creating an AWS IAM role from the console:
1. In the AWS console's navigation pane, choose Roles, Create role.
2. For Role type, specify Another AWS account.
3. In Account ID, type the AWS account id to which you want to grant access to your
resources.
4. Choose Next: Permissions, and select a permission policy from the list. To create a new
policy, choose Create Policy.
5. Choose Next: Tags, and add an optional tag.
6. Choose Next: Review, and for Role Name type a unique name for the role (not case
sensitive). Type an optional Description for Role description.
7. Choose Create role.
8. Provide users in the trusted account with permissions to switch to the role in the console.
See Granting a User Permissions to Switch Roles.

Orchestration Information Appears On the Assets Page:

Once you have configured Orchestration you will be able to see the information coming from the
orchestration on your Assets page. The Assets page features an Orchestration column that shows
whether it's a VSphere, AWS or K8s asset. Metadata coming from the AWS orchestration includes
IP addresses, MAC addresses, security groups and tags (tag made of key and value is assigned to
any new VM in AWS), instance ID and more. AWS tags are useful for Reveal grouping (Production,
Testing, etc.), segmentation policies (labels) and File Integration Monitoring (FIM).

4.1.3 Azure Orchestration
Intro
Azure Orchestration enables you to complement the information provided by GuardiCore Agents.
For example, information coming from Azure orchestration may include Azure tags assigned to the
asset, and more. Find more information about Azure Tags here.
How to Configure Azure Orchestration

To configure Azure orchestration you will need to configure a read-only user in the Azure account,
assign user permissions and configure Azure orchestration in the management.
Configure a read-only user in the Azure account
1. Login to the Azure portal.
2. Choose Azure Active Directory > App Registrations.
3. Click on New application registration and fill in the fields. Note that the URL field is not
important; you only need to add the clients system URL.
4. Configure a key for the application.
Add permissions to application user
1. Locate the subscription you want to cover using the orchestration and click Access control
(IAM).
2. Add the application user you created to the 'Reader' role. Note that you need to add the
reader role to each subscription that you want to cover in the orchestration.
Configure Azure orchestration in the Centra management
1. From Administration, select Orchestrations.
Note: Each orchestration will be configured per subscription. So for example if you have 3
subscriptions under your Azure account you will be required to configure 3 separate
orchestrations with the same user.
2. Fill in the fields:
○ Name - set a name, makes most sense to use the subscription name.
○ GC Cluster - choose the correct cluster the orchestration should run from.

○ Tenant id - add tenant ID of Azure target environment, referred to as 'directory id'

in the UI.
○ Subscription Id - add target subscription ID within the account.
○ Application Id - add the orchestration user application ID.
Important notes
● Tag info is fetched every 30 seconds by default.
● Full VM info is pulled every 30 minutes by default, configured by the new parameter at the
bottom 'Orchestration IP cache timeout'.
● The Azure API allows only 12k calls an hour, so for example if you want full data fetch each
minute you are limited to 200 assets before the API starts glitching.
● In release 29, In case of an API error the orchestration will crash and restart. Log should be
visible as any system log.
● Asset info update interval needs to be changed if there are more than 10K assets within
the account.

4.1.4 GCP Orchestration
Intro
enables you to import orchestration data from GPC (Google Cloud Platform). When GCP
orchestration is configured, Centra's Aggregator connects to the GCP API to pull metadata on
GPC workloads.
Configuring GCP Orchestration

There are two major steps to configuring GCP orchestration:
Step 1: Set Up a Read Only Service Account in GCP.
Step 2: Add GCP orchestration to Centra.
These steps are explained in the following sections.
Step 1: Set Up a Read Only Service Account in GCP
1. Create a Project in GPC (see GCP’s Create a Service Account).
2. In the top-left corner of the GCP console, click Menu and select IAM & Admin/Service
accounts. The Create Service Account dialog box is displayed.
3. Enter a name and description for the service account and click Create.
4. Assign the role of Project viewer to the new account.
5. Click Continue/Create Key.
6. Ensure the key type is set to JSON and click Create.
You'll see a message that the service account JSON file has been downloaded to your
computer.
7. Make a note of the location and name of this file. You will need it later.
8. Assign the service account permissions to the additional projects that need to be covered
with Centra. No need to create a service account per project.
9. Click Close/Done.
10. In the list of service accounts, click the email address that relates to the service account
you created and click Edit.

11. Click View Domain Wide Delegation Client ID.

12. In the Product name for the consent screen field, enter a product name.
13. In the Email address field, use the default email address or assign a new email address.
14. Click Save.
Step 2: Add GCP Orchestration to Centra

1. In Centra’s Administration menu select Data Center/Orchestrations and click the + Add
Orchestration button. The Add New Orchestration dialog box appears:


2. In the Add New Orchestration dialog box specify the following:
Field Value
Type GCP
Name Name of the Orchestration
GC Cluster Aggregator cluster on which this orchestration should be deployed
Service Account Service account email of the account created in the previous section
Project List This option allows you to configure more than one project per orchestration. Add
a comma delimited list of project IDs.
Private Key Paste the private key downloaded in the previous section.
Label Key
Translation Enables you to control the way imported labels appear in Centra, So, for example,
you can specify that a tag such as OrchestrationAppName should be imported
into Centra as App.
Labeling Strategy This refers to how you want to import custom Tags into Centra.
Three strategies are provided:
Enabled: all custom orchestration Tags will be imported into Centra.
Disabled: no custom orchestration Tags will be imported into Centra.
Predefined: List the custom Tags to import into Centra. This is done by supplying a
list of keys to import.
Note: Labeling Strategy only affects custom tags that users created for F5 and
does not affect the importation of metadata.
Predefined Labels List the keys to import as labels. This only applies to custom tags.
Metadata Labels When this is checked, GCP metadata is imported as labels.
Orchestration Full Number of seconds to elapse before another orchestration report is generated.
Report Interval
As with other Orchestrations, once you have configured the GCP orchestration you will be able to
see the information coming from the orchestration on your Assets page.

4.1.5 OCI Orchestration

Intro
enables you to import orchestration data from OCI (Oracle Cloud Infrastructure). When OCI
orchestration is configured, Centra's Aggregator connects to the OCI API to pull metadata on OCI
workloads.
Configuring OCI Orchestration

There are two major steps to configuring OCI orchestration:
Step 1: In OCI, create an orchestration user for Centra.
Step 2: In Centra, configure the OCI orchestration.
Step 1 - In OCI, create an orchestration user for Centra

Follow the steps in the OCI guide to create the OCI orchestration user for Centra. This includes
the following steps in the guide:
1. Create a user in IAM for the Centra system who will be calling the API, and provide the
user read only access to the desired tenant\s.
2. Get these items:
1. RSA key pair in PEM format (minimum 2048 bits). See How to Generate an API
Signing Key.
2. Fingerprint of the public key. See How to Get the Key's Fingerprint.
3. Tenancy's OCID and user's OCID. See Where to Get the Tenancy's OCID and
User's OCID.
3. Upload the public key from the key pair in the Console. See How to Upload the Public Key.

4. Make sure you take note of the user OCID, key pair fingerprint, private key and tenancy
OCID and region.You will need these for the next step.
Step 2 - In Centra, configure the OCI orchestration
1. In Centra’s Administration menu select Data Center/Orchestrations and click the + Add
Orchestration button. The Add New Orchestration dialog box appears:
2. In the Add New Orchestration dialog box specify the following:

Field Value
Type OCI
GC Cluster Aggregator cluster on which this orchestration should be deployed.
User OCID OCID of the user calling the API. See Step 1 above.
Key Pair Fingerprint See Step 1 above for how to obtain the key pair fingerprint.
Private Key Content of the private key in PEM format. See Step 1 above for how to obtain
this.
Private Key Passphrase Passphrase for the key if it is encrypted.

(optional)
Tenancy OCID OCID for the tenancy. See Step 1 above for how to obtain this.
Region OCI home region. See Regions and Availability Domains for more information.
Query All Regions When checked, queries all regions subscribed by the tenancy. Customers that
use more than one region can choose to query all regions which will enable the
orchestration to pull information for assets that are in other regions as well.
As with other Orchestrations, once you have configured the OCI orchestration you will be able to
see the information coming from the orchestration on your Assets page.

4.1.6 Openstack Orchestration
enables you to import orchestration data from the OpenStack cloud operating system. When
OpenStack orchestration is configured, Centra pulls metadata from OpenStack and converts them
to Centra Labels.
Setting Up OpenStack Orchestration
Setting up OpenStack Orchestration consists of two steps:
Step 1: Configuring a read-only user on the OpenStack platform.
Step 2: Configuring OpenStack Orchestration in Centra.
Step 1: Configure a read-only user on the OpenStack platform
The following instructions are performed using the OpenStack CLI.
1. Create a Guardicore user:
user add <user name> --domain <domain>
2. Configure the password for the created user:
user set <user name> --password <password>
3. Add a reader role for the Guardicore user and specify the domain\projects to be covered by
the orchestration. A ‘reader’ role should be configured by default as part of the OpenStack
deployment. If it’s missing please contact the OpenStack administrator to create one. The
following CLI command applies to the whole domain:
role add reader --domain <domain name> --user <user name>
Step 2: Configure OpenStack Orchestration in Centra
1. Go to Administration > Data Center > Orchestration.

2. Click + Add Orchestration.
3. Select OpenStack. The following dialog box appears:


4. Fill out the fields as described in the following tables:
Basic Configuration
Field Description
Name A descriptive name for the orchestration
GC Cluster Select the relevant GC cluster.
Admin User The User Name for the Guardicore User created in Step 1 in OpenStack.
Admin The User Password for the Guardicore User created in Step 1 in OpenStack.
Password
Projects List The project list to be covered by the orchestration. The list can be provided by
‘project ID’ or ‘project name@domain’ name format delimited by a new line.
Example Project ID: 3e434d8b1aa94b12a21507f6f3577038
Example Project name: @domain example - projectA@default
Auth Url The API public authentication endpoint. The Endpoint can be discovered by
running the following from the console:
endpoint list --service identity --interface public

User Domain The domain of the Guardicore user created in Step 1.

Name
User domain can be discovered by running the following:
user show <user name>
and looking at the domain_id value.
User Domain The domain ID of the Guardicore user created in Step 1.

ID (optional)
User domain can be discovered by running the following:
user show <user name>
and looking at the id value.
Metadata Enable/Disable metadata labels

Labels
Labeling Provisioning of orchestration tags in Asset labels:

Strategy Enabled/Disabled/Predefined
Predefined List of label keys to load from orchestration when labeling strategy is set to
Labels predefined
Label Key A list of label keys to translate on import; each origin label key should be
Translation followed by -> and the target label key. For example,
"OrchestrationAppName->App"
Advanced Configuration
This configuration is used to mitigate the performance impact on the Openstack controller:

Field Description
Fetch Hosts Whether to fetch hosts
Fetch Users Whether to fetch VMs’ users
Fetch Flavors Whether to fetch VMs’ flavors
Fetch Images Whether to fetch VMs’ images names
Full Port Pull Strategy for full port pull (occurring every Orchestration Full Report
Strategy Interval):
AllAtOnce: Pull all ports at once
AllPulledServersInBulk: Pull ports for all pulled servers, in bulk (bulk size
is set by Ports Pull Bulk Size). For example, if bulk size is 50, then first, all
ports for the first 50 servers will be pulled, then all ports for the next 50
servers, and so on.
Differential Port Strategy for differential port pull:

Pull Strategy
AllAtOnce: Pull all ports at once
AllPulledServersInBulk: Pull ports for all pulled servers (existing + new), in

bulk (bulk size is set by Ports Pull Bulk Size)
NewServersOnlyInBulk: Pull ports for new pulled servers only, in bulk

(bulk size is set by Ports Pull Bulk Size)
NoPull: Do not pull ports differentially

Ports Pull Bulk Size How many ports to pull in each bulk. Relevant only for
AllPulledServersInBulk and NewServersOnlyInBulk modes.
0: special value - fallback to default (50)
Interval Between Sleep interval between per-server ports pulls (in milliseconds)
Ports Pulls
Servers Pull Bulk How many servers to pull in each bulk. Relevant for all modes.
Size
0: pull all servers at once
Interval Between Sleep interval between server's bulk pull (in milliseconds)
Server Pulls
Keystone Version Identity Protocol Version
Nova Version Compute Protocol Version
Orchestration Full Interval in which to run a full report (in seconds)

Report Interval
4. Click Test Connection to verify credentials. The test connects to the API endpoint and
tests connectivity to the nova-client:list-servers and neutron-clients list-networks.
5. If the Test Connection is successful, click Save.

API Commands
The following API commands are used by Guardicore:
API Command Respective Command in CLI
neutron_client.list_networks openstack network list
neutron_client.list_ports openstack port list
neutron_client.list_floatingips openstack floating ip list
nova_client.servers.list openstack server list
nova_client.hypervisors.list openstack hypervisor list
nova_client.flavors.list openstack flavor list
keystone_client.projects.get openstack project show <name/id>
keystone_client.users.list openstack user list
nova_client.glance.list openstack image list

4.1.7 Active Directory Orchestration
Configuring orchestration of the Active Directory with Centra is required for creating Centra User
Groups. For more information about this feature enabling user-based segmentation, refer to the
User Groups article in the Admin Guide.
To add AD orchestration to Centra:
1. In the Centra Administration menu, select Data Center/Orchestration, and click the
+ Add Orchestration button. The Add New Orchestration dialog box appears.
2. In the Add New Orchestration dialog box, for Type, select Active Directory:
The following fields are displayed:

3. Fill out the fields as described in the following table:
Field Description
Name The name that you want to use to identify the AD orchestration.
GC Cluster The Guardicore Cluster that you want to use for the AD orchestration.

Domain Name The domain name of the organization for which you are configuring the AD
orchestration. This is the root domain of the entire AD tree hierarchy. For a detailed
understanding of AD structure and domains see Active Directory Structure and
Storage Technologies.
Login Username The user logon name according to the userPrincipalName (UPN) format for the
Active Directory as explained in User Naming Attributes. A UPN consists of a UPN
prefix (the user account name) and a UPN suffix (a DNS domain name).
Login Password The user logon password.
Base DN The section of the directory where the application will commence searching for
(optional) Users and Groups. For users to be found in an application, they must be located
underneath the base DN. The Base DN speeds up the search for users.
Servers The domains or IP addresses of the AD servers.
Use SSL Select to use SSL for the orchestration. To use this mode, make sure that Active
Directory Certificate Services are enabled or use Insecure mode.
4. Click Test Connection and if the connection is successful, click Save.

4.1.8 Inventory API Orchestration
Inventory API is a dedicated Guardicore orchestration designed to create assets in agent-less

environments. To enable scenarios in which asset information is fed to Centra from a
decentralized system (such as Chef recipes running on individual machines), Guardicore added an
API to allow adding new assets or information about assets. "Inventory" refers to assets,
containers etc.
This API enables customers to easily add a large amount of asset information to Centra, using
REST API calls to Aggregators (unlike the REST API that calls Management). Once enabled,
customers' scripts and automations will be able to create and name new Centra assets (even
without Agents) and add labels to existing assets in a distributed fashion. By replacing IP
addresses of agentless workloads with real asset names, customers get more context when
browsing Reveal maps and building segmentation policies. An asset added through this API will
appear on the Assets page with Inventory API in the Orchestration column.
Note: Inventory API Orchestration v2.0:

The new and upgraded version of the inventory api (v2.0) is available as
well, and the instructions for setting it up are the same. The original version
is still supported but it’s main usage is for existing environments that are
already configured to work against the previous version. We strongly
encourage you to use the v2.0 if you are setting up a new environment.
Note that the orchestration configuration is the same, except for the REST
call itself.
The new API version accepts MAC addresses while the original version
does not.
When to use the Inventory API?
The new orchestration should be used in the following cases:
● The user wants to report workload labels from the workloads themselves (for example,
using Chef recipes) and these labels might change. These workloads can be with or
without Agents.

● Customers have a centralized, continuously updated inventory of assets, which they

want to keep in sync with Centra. The inventory must have, for each server, either a
BIOS UUID, or its IP and MAC. Is also possible to use only IPs, but in that case, if an
Agent is installed on the asset, a subsequent report by an Agent will not be matched to
the asset.
Why Use the Inventory API?
Creating assets using this method results in an improved experience for the customer:
● Users can replace "unknown IPs" with labeled assets, instead of using labels.
● System performance is better when using assets instead of dynamic IP criteria.
How it works
An automation tool, running on the customer premises, calls a REST API method on the
Aggregators. This call contains specific asset parameters: name, IP and more. The Aggregator
then reports these assets to Centra, where they'll appear as if they arrived from a regular
orchestration. As with other orchestrations, these reports are merged with asset information
from other sources (other orchestrations and Agent information), so it's safe to report asset
information, regardless of its coverage by other orchestration engines.
Configure the Inventory API
1. From Administration go to Data Center > Orchestrations and select InventoryAPI. The
Add New Orchestration dialog box appears:


2. Fill out the fields in the dialog box:
Field Value
Type InventoryAPI
GC Cluster Aggregator cluster on which this orchestration should be deployed.

There can be multiple Inventory API Orchestrations per cluster.
REST Username Username for authenticating the Inventory API.
The created users are not related to Centra users in any way; Centra
credentials cannot be used as REST API credentials or vice versa.
Note: you can create multiple user/password credentials by creating

multiple orchestrations of this type.
REST password Password for authenticating the Inventory API.
Integration Token Integration Token for authenticating the Inventory API.
Authentication Authentication scheme to use for authenticating the Inventory API:

Scheme ● User password
● Integration token
● User password and Integration token
Allowed Incoming Defines who can access the orchestration/sources.

(optional)
List the allowed source incoming CIDR blocks from which the
Aggregators will get the REST API calls, in the form of “X.Y.Z.W/len”
separated by commas.

Report Expiration Number of seconds an asset is considered "on" after the user has
last reported it to orchestration.
Important Note: After the expiration time is over, if an asset wasn't

reported to the REST API orchestration, it will be marked as "deleted"
as we assume it no longer exists. To prevent an asset from moving to
the "deleted" state, the Inventory API Orchestration must get
continuous reports about the asset.
Labeling Strategy This refers to how you want to import custom Tags into Centra. Three
strategies are provided:
Enabled: all custom orchestration Tags will be imported into Centra.
Disabled: no custom orchestration Tags will be imported into Centra.
Predefined: List the custom Tags to import into Centra. This is done
by supplying a list of keys to import.
Note: Labeling Strategy only affects custom tags that users create
and does not affect the importation of metadata.
Predefined Labels List the keys to import as labels. This only applies to custom tags.
Metadata Labels When this is checked, metadata is imported as labels. Optional

parameters which will be attached to the asset and reported to the
management console.
Orchestration Full Number of seconds to elapse before running another full report.
Report Interval
Label Key Translation Enables you to control the way imported labels appear in Centra, So,
for example, you can specify that a tag such as
OrchestrationAppName should be imported into Centra as App.
3. To create a Centra asset, call the REST API method on any of the Aggregators in the
defined cluster. The REST API call can contain information about one or more assets.
Each asset should contain the following information:

Asset ID A unique ID for this asset. This unique ID must be created by the
customer automation, and must be reused when reporting the same
asset on subsequent calls.
Asset name This name will appear in Centra's Reveal maps and asset views.
BIOS UUID The asset's BIOS UUID. Necessary in case the asset has an Agent
installed on it (during report time or in the future). See below for ways
to get this value.
List List of Asset's nics: a list of dictionaries in the following format:
{ "mac_address": <mac>, "addresses": <list of IPv4 and IPv6 IPs> }
If only IPs are present, it’s possible to send only one dictionary with
the IP addresses: { "addresses": <list of IPv4 and IPv6 IPs> }
Note: If the mac data is missing, the BIOS UUID must be given in
case the asset has an Agent installed on it (during report time or in
the future).
Labels A list of label keys and values, attached to the assets.
Metadata Optional parameters which will be attached to the asset and reported
to the management console.
An asset added through Inventory API will be displayed on the Assets page with Inventory API
in the Orchestration column:

REST API Example- v1.0
The Aggregator serves the REST API from the same server and certificate as the "Guest Installer"
HTTPS interface (which is used for Agent installation script download). If an FQDN is used, it can
be used for these REST API calls as well (with proper certificate usage).
1. The REST endpoint is https://<aggregator IP or FQDN>/api/v1.0/assets
2. Do a POST REST API call
3. Use HTTP basic authentication to include username+password credentials
4. Add "?token=XXX" to your HTTP query parameters to include a token, if required
5. In the request body, put the asset information as described above. For example:
"assets":[
"id":"422F81AE-781B-4823-F1FD-7E51093BF316",
"bios-uuid":"422F81AE-781B-4823-F1FD-7E51093BF312",
"name":"lin-lin-Agent20",

"addresses":[
"172.17.2.52",
"100.100.102.52",
"200.200.202.52"
],
"labels":[
"key":"Role",
"value":"Server"
},
"key":"Deployment",
"value":"API"
CURL usage example for same call (without TLS verification):
curl -k -d '{"assets":[{"id": "422F81AE-781B-4823-F1FD-7E51093BF316",

"bios-uuid": "422F81AE-781B-4823-F1FD-7E51093BF312",

"name":"lin-lin-Agent20", "addresses":["172.17.2.52",
"100.100.102.52", "200.200.202.52"], "labels": [{"key": "Role",
"value": "Server"}, {"key": "Deployment", "value": "API"}]}]}' -u
gc-api:password -H "Content-Type: application/json" -X POST
https://172.16.100.50/api/v1.0/assets
REST API Example- v2.0
The Aggregator serves the REST API from the same server and certificate as the "Guest Installer"
HTTPS interface (which is used for Agent installation script download). If an FQDN is used, it can
be used for these REST API calls as well (with proper certificate usage).
1. The REST endpoint is https://<aggregator IP or FQDN>/api/v2.0/assets
2. Do a POST REST API call
3. Use HTTP basic authentication to include username+password credentials
4. Add "?token=XXX" to your HTTP query parameters to include a token, if required
5. In the request body, put the asset information as described above. For example:
{
"assets":[
{
"id":"422F81AE-781B-4823-F1FD-7E51093BF316",
"bios-uuid":"422F81AE-781B-4823-F1FD-7E51093BF312",
"name":"lin-lin-Agent20",
"nics": [{
"mac_address": "00:21:56:9d:03:89",
"addresses": ["100.101.102.106", "200.201.202.206"]}
],
"labels":[
{
"key":"Role",
"value":"Server"
},
{

"key":"Deployment",
"value":"API"
}
]
}
]
}
CURL usage example for same call (without TLS verification):
curl -k -d '{"assets": [{"name": "server1", "id":

"422F81AE-781B-4823-F1FD-7E51093BF316", "instance-id":
"799F81AE-781B-4823-F1FD-7E51093BF318", "bios-uuid":
"422F81AE-781B-4823-F1FD-7E51093BF312",
"metadata":{"os":"ubuntu14.04"}, "labels": [{"key": "Role", "value":
"Server"}, {"key": "Environment", "value": "Test"}], "nics" :
[{"mac_address": "00:21:56:9d:03:89", "addresses":
["100.101.102.106","200.201.202.206"]}]}]}' -u gc-api:password -H
"Content-Type: application/json" -X POST
https://172.16.100.50/api/v2.0/assets
Limitations
● If you report an asset without a BIOS UUID, a subsequent report by an Agent will not be
matched to this asset. The management server does not match assets reported through
this orchestration with Agent information according to IP address. At the moment there is
no way to report AWS instance ID or other matching parameters - you must use IP & BIOS
UUID.
● Assets reported just once using the Inventory API will eventually expire; there is no way to
report assets which will stay 'indefinitely'; the REST API method must be repeatedly called
to keep the asset as "On”.


4.2 Exportables Configuration

4.2.1 Syslog
Syslog is a common format for message logging. The administrator uses the Add New Syslog
integration dialog box to configure Syslog (as described below), and can configure multiple hosts
for Syslog by using the dialog box repeatedly. Each time a Syslog Integration is configured, the
configuration is added as a row in the Syslog Integration screen:
Centra provides two types of Syslog integration:
Events Syslog Exporter: enables you to export a wide range of data to Syslog including incidents,
system alerts, Agent and Audit logs, messages, etc.
Network Log Syslog Exporter: enables exporting the Network log which provides data on
connections including type of connection, how Centra handled the connection, time of connection,
as well as detailed source and destination information. To enable the Network Log Syslog

Exporter, your administrator must execute a few CLI commands (see Enabling the Network Log
Reporter).

Configuring Syslog Export
The administrator can configure the incidents to be exported to Syslog by performing the
following:
1. From Administration, select Data Export > Syslog:
The Syslog Integration screen is displayed:
2. Click the + Add syslog Integration button to display the following dialog
box:

3. Select either Events Syslog Exporter or Network Log Syslog Exporter and complete the
fields as explained below:
Events Syslog Exporter
If you selected Events Syslog Exporter, the following dialog box appears:


4. Fill in the fields as specified in the following table:
Field Explanation
Name Type a name for the Syslog Integration.
Type Events Syslog Exporter appears here if you selected it in the Add New Syslog
Integration dialog box in step 2 above.
Connection Options
Syslog Host The IP of the target Syslog server.
Syslog Port Different servers might require different ports (syslog UDP is usually 514).
Syslog Protocol TCP or UDP
Export through In some SaaS deployments, in order not to open extra ports, it is possible to
Aggregators configure the Aggregators to export the syslog to the syslog server. If this
feature is enabled, you must also enable the Cluster Exporter in the
Aggregator screen (From Components/Aggregator select the Aggregator,
then select the More button, Override Configuration, Show Advanced
Options. Under Advanced Options, select Aggregator/Aggregator features,
and the Cluster exporter checkbox:

Use TLS Encrypt Syslog Traffic with TLS (works only with the TCP protocol). Syslog
records can be sent over a secure channel, as indicated in RFC 5425. This is
common practice when the syslog channel is sent over the public internet or
other unsafe networks. The TLS protocol ensures the syslog messages are
securely sent and received over the network.
After setting the general Syslog settings (host, port and export settings), do
the following to enable TLS encryption for the Syslog channel:
● Make sure your Syslog Protocol is set to TCP.
● Make sure the Use TLS box is checked.
Verify Host This field should always be checked; it verifies that the host domain presents a
valid certificate. If this box is not checked, the TLS protocol will be used but
there is no guarantee that the data is not intercepted by a third party.
● If the host is a domain name such as "listener.logz.io", Centra will

verify a valid certificate which matches the configured syslog
hostname.
● If the host is an IP address, a server CA certificate must be provided

in order to successfully verify the destination IP.
CA certificates Required if the server's certificate is signed by an internal Certificate

Authority. In this case, a custom CA certificate chain must be given for the
host verification to succeed. This is usually not required for syslog servers on
the public internet, such as Sumo Logic or Logz.io. The server CA chain should
include all the certificate chains for each issuer you are willing to trust in a
PEM format.
Client certificate Required if the syslog server performs client authentication. In this case, a
specific client certificate should be given in order for Centra to successfully
connect to the syslog server.
This is usually not required for syslog servers on the public internet, such as
Sumo Logic or Logz.io.
Exporting Options
Export Incidents Choose whether to export incident information. Note that Exporting
incidents is subject to filters defined in System > Configuration > Exporters.

Export system alerts Choose whether to export System alerts to Syslog.
Alert minimum severity The minimum alert severity to be exported: completed, info, warning, error
Export agents log Choose whether to export the Agents log to Syslog.
Export audit log Choose whether to export Audit log information.
Export full changes of Export full changes of segmentation policies (may include sensitive
segmentation policies. information).
Export label changes log Choose whether to export Label changes log information.
Log messages to file Choose whether to log all sent messages to a local file on the sending
machine.
Report agent events Produces a report showing events according to Agents.

individually
Report agent labels to Includes the Agent labels in the syslog report.
syslog
Agent labels list reported Enables you to specify the Agent labels that will be reported in syslog.
to syslog
Message Format
Message Format Native, CE, or RFC 5424:
Native: Guardicore format
CEF - Common Event Format (CEF) is a Logging and Auditing file format from
ArcSight. CEF is an extensible, text-based format designed to support
multiple device types by offering the most relevant information. The CEF
format description can be reviewed here: CommonEventFormatV25.pdf
RFC 5424

Syslog protocol (RFC-5424) compliant message format. This format can be

applied to all syslog records sent from Centra (including audit logs, system
events, incidents etc.) over Management or Aggregator.
04-23-2019 19:13:26 User.Critical 10.0.1.6 1 2019-04-23T16:13:24Z Guardicore Guardicore-Centra

- Audit - New audit log entry reported by the GuardiCore Security Suite;;Username: admin;IP
Address: 10.15.1.10;;Title: Run Syslog Integration Test Connections;;Description: None
RFC-5424 Structured Structured data elements as specified in RFC 5424, without brackets. E.g.
Data Sumo Logic cloud syslog source token.
Network Log Syslog Exporter
When Network Log Syslog Exporter is selected in the Type field of the Add New Syslog Integration
dialog box, a dialog box with fields similar to the Events Syslog Exporter dialog box above appears,
with the exception of the Exporting options:
Fields Explanation
Exported verdicts Centra’s verdict on how to handle the connection (corresponds to the
Action filter in the Network log). Possible verdicts are Blocked, Will be
Blocked, Alerted, Could not Block, Allowed.

Filter by labels Enables filtering log entries whose source or destination belong to the
specified label key and value.
Export label keys Adds label info of specified keys to exported network logs.
5. Click the Test Connection button to test the connection and then click Save; the
configuration is added as a row in the Syslog Integration screen.
Common Event Format (CEF) sent by Centra

The following are example of CEF messages sent by Centra
Bad reputation
<10>Mar 7 13:45:13 host CEF:0|GuardiCore|Centra|unknown|Reveal Incident|Bad

Reputation|medium|src=172.17.0.22 shost=win-win-Agent2 dst=216.58.208.131 smac=N/A
start=2018-03-06 13:28:46 act=ALERTED_BY_MANAGEMENT msg=Suspicious activity detected on
172.17.0.22 dhost=N/A
Lateral movement
<10>Mar 7 13:45:13 host CEF:0|GuardiCore|Centra|unknown|Deception Incident|Lateral

Movements|high|src=100.100.100.1 dpt=22 shost=lin-lin-Agent1 proto=TCP dst=100.100.13.23
start=2018-03-06 16:55:19 act=ALERTED_BY_MANAGEMENT msg=Suspicious network activity
detected between 100.100.100.1 and 100.100.13.23 dhost=N/A
Network scan
<10>Mar 7 13:45:13 host CEF:0|GuardiCore|Centra|unknown|Network Scan Incident|Network

Scans|medium|msg=Network scan detected originated by 200.200.200.254 start=2017-08-01
12:25:10 src=200.200.200.254 shost=N/A act=ALERTED_BY_MANAGEMENT
Integrity

<10>Mar 7 13:45:13 host CEF:0|GuardiCore|Centra|unknown|Integrity Incident|Integrity

Violations|low|msg=Suspicious activity detected on N/A start=2018-03-01 16:24:35 src=N/A
shost=lin-lin-Agent4 act=ALERTED_BY_MANAGEMENT
System Event
<10>Mar 7 13:45:13 host CEF:0|GuardiCore|Centra|unknown|System Event|Exception in

management service 'management'|ERROR|msg=Uncaught exception in service
management\\nTraceback (most recent call last):\\n File '/Applications/Py...<truncated>
id=fdba044b-dcd9-4629-96f2-647cec3df8ab
Audit log
<10>Mar 7 13:45:13 host CEF:0|GuardiCore|Centra|unknown|Audit Record|Audit Rec
Enabling the Network Log Reporter
Before using the Network Log Syslog Exporter, the administrator must enable the Network Log
Reporter that reports logs to the Network Log Syslog Exporter.
Follow these steps:
1. On the MGMT master node, run:

gc-mgmtctl set_conf --group management --option network_log_reporter --value true
2. Run: gc-cluster-cli service-restart --service_name visibility-ingestion-server

4.2.2 Email
Centra allows you to subscribe to incidents and/or system alerts. This way you will receive an
email every time an incident or system alert has been logged. Configuration varies between SaaS
users and on-premises users.
SaaS Users
The SMTP configurations are done by GuardiCore so SaaS users don't need to configure anything.
You only need to select the type of alerts you wish to receive - Incident Alerts, System Alerts or
both - and fill out related fields.
1. To choose the alerts you wish to receive, from Email Integration select Subscriptions > Alerts.
2. Check Enable Incident Alerts and/or Enable System Alerts to subscribe to the service.
Note: if you check Enable Incident Alerts, go to System > Configuration > Exporters to set the
severity level for incident alerts.

3. In Alert minimum severity select the alert severity level. The severity levels -
Info/Warning/Error - correspond to the severity levels of the System Log (Administration >
System >Log). This configuration defines the minimum severity that will trigger an email alert.
4. In Email addresses type the email address/addresses to send the incidents and alerts email to.
5. Click Save Changes.
On-Premises Users
On-premises users need to first set SMTP configurations and then subscribe to the alerts service.
1. SSH to Management and type the following CLI command: gc-mgmtctl --import_all set_conf
--group email_smtp --option force_show_smtp_configurations --value True. The SMTP Setup
screens appears.
2. Fill in the SMTP Setup page with your organization's details.

3. Next, choose the alerts you wish to receive, from Email Integration select Subscriptions >
Alerts.
4. Check Enable Incident Alerts and/or Enable System Alerts to subscribe to the service.

Note: if you check Enable Incident Alerts, go to System > Configuration > Exporters to set the
severity level for incident alerts.
5. In Alert minimum severity select the alert severity level. The severity levels -
Info/Warning/Error - correspond to the severity levels of the System Log (Administration >
System >Log). This configuration defines the minimum severity that will trigger an email alert.
6. In Email addresses type the email address/addresses to send the incidents and alerts email to.
7. Click Save Changes.

4.2.3 Slack
Integrate with Slack to export Guardicore incident messages to your corporate Slack platform.
Export Incidents to Slack
Check this box to allow integration with Slack
Export audit log to Slack
Export logs to Slack.
Slack site name
A unique URL used for reporting incidents.
Slack webhook address
This URL accepts notifications from Guardicore and passes it into Slack.

4.3 Integrations
4.3.1 Integration with Palo Alto Networks Firewall
The integration of Guardicore Centra with Palo Alto Networks leverages Centra unique breach
detection capabilities and Palo Alto Networks firewall access control capabilities. The joint
solution allows security administrators to proactively block IP addresses of compromised assets to
gain control of the attack. As part of the attack mitigation, the IP address of the compromised
asset is automatically forwarded to the Palo Alto firewall from the Reveal map.
Guardicore Centra uses various techniques to detect zero day attacks in data centers, including
dynamic deception, reputation and policy based micro-segmentation. Once an attack is detected,
Guardicore Centra updates Palo Alto firewall with the IP address of the compromised host. The
Firewall then blocks connection attempts to and from the compromised asset, blocking its ability
to propagate in the datacenter.
How It Works
The process begins with Centra identifying a suspicious IP address that has generated a High
Severity incident. The IP can be either external, i.e. coming from the Internet, or part of internal,
east-west traffic. Once the IP is detected, it is relayed to Palo Alto Networks Panorama which then
blocks all connection attempts to and from the compromised asset through the NGFW, blocking
its ability to propagate in the data center. Centra can be configured to send this information
automatically or manually directly from its Reveal map. IPs are collected from all Centra’s
platforms including deception servers, Reveal maps and reputation servers.

Guardicore Palo Alto Networks Integration Diagram
The joint solution allows security administrators to proactively block compromised assets inside
the data center from performing data exfiltration or carrying out lateral movement. As part of the
attack mitigation, the IP address of the compromised asset is reported to the Palo Alto Networks
firewall which can cut the attacker’s communication line with its C&C server or prevent it from
exfiltrating previously stolen data.
Before You Begin: Requirements for Successful Integration
1. Deploy Guardicore Agent on Endpoints and Ensure Connectivity to Centra Manager.
2. As a best practice, for API access to Palo Alto Networks Panorama, set up a separate admin
account for XML API access to Panorama by following these steps:
a. Select an Admin Role profile.
b. From Panorama>Admin Roles, select or create an admin role.

c. Select features available to the admin role:
i. Select the XML API tab.
ii. Enable or disable XML API features from the list, such as Report,
Log, and Configuration.
iii. Select OK to confirm your change.
Assign the admin role to an administrator account.
Configuration
Configuring Centra and Palo Alto Firewall integration is easily accomplished using Centra's Admin
panel and Palo Alto's Firewall.
To configure integration with Palo Alto, follow these steps:
1. On the Administration menu, select Mitigation & IoCs and click Firewall Mitigation.

The Firewall Mitigation dialog box appears.
2. In the Firewall Mitigation dialog box, check Enabled:
Note that Centra provides separate configuration options for external and internal IPs. The
default value for both External IPs Action Mode and Internal IPs Action Mode is Manual:

In Manual mode you send suspected IPs to the firewall by first selecting incidents in the
Lateral Movement, Policy Violations, or Bad reputation Incident screens (or in All Incidents),
displaying the incident's Report, and then clicking the button in the
report's Recommended Actions section.
Make sure that you use the same tag in Palo Alto Dynamic address group as used in the Internal
IPs Tag and External IPs Tag:

Palo Alto UI
3. On the Administration menu, select Integrations > Firewalls.
4. On the Firewalls Integration page, configure the Palo Alto firewall fields and whether to
report to all firewalls or to specific ones.

5. After completing the configuration and clicking Save Changes, you should be able to see
the Report IP to Firewall button in the Recommended Actions section of an incident's
Report page (If you have set Action Mode to Manual in the Firewall Mitigation page as
described above; if you've set it to Automatic, the IP will be automatically reported):

Similarly, if you have specified Manual mode in the Firewall Mitigation dialog, you can report an IP
of any asset on the Reveal map, even if this asset is not part of an ongoing incident. In the asset's
Asset information panel, click the Report IP to Firewall button as shown in the following figure:

Troubleshooting
1. Verify connectivity between Centra and Panorama: perform “TEST CONNECTION” to

verify that Centra can access Panorama using REST API.
2. Verify that “show firewall integration” is enabled on Guardicore Centra.
3. Verify that the Dynamic address groups are defined on both systems.

4.4 Authentication And User Management

Configuration
The following articles describes the process of configuring various LDAP and SAML 2.0
authentication options with Centra. Further at the end of this section, an article called “Permission
Schemes” describes how to configure the access of the identity provided users to Centra.
To start the process of configuring, head to Administration > User Directories > Add User
Directory.
4.4.1 LDAP SSO
I order to configure the LDAP SSO, a basic user of the AD is sufficient.

For example, the “Domain Users” default group has the rights to read user, group and computer
objects from the DC.
This can be hardened and behave differently, however the default behaviour of MS AD is as
described above.
Prior to configuring the integration, make sure with the client that the user used for the
integration is configured as above.
To configure LDAP (default):
1. Fill in the fields in the Add New User Directory dialog box:

Field Description
Type LDAP (default)
Name Enter the Fully Qualified Domain Name (FQDN)
Login Username Type the username of the service account that will be used to connect to the domain.
Login Password Type a password.
Base DN The root distinguished name (DN) to use when running queries against the directory
server.
LDAP Providers A list of servers (domain name or IP) through which the connection to the domain will be
made.
Use SSL Click this checkbox to secure the directory with SSL.

Enable Kerberos Centra FQD: Centra Domain Name, i.e. Centra.domain.com

authentication Realm: Active Directory Domain -- case sensitive and by convention, UPPER CASE
Keytab: click to upload a new keytab file (All Kerberos server machines need a keytab
file, called /etc/krb5.keytab, to authenticate to the KDC (Key Distribution Center). See
Kerberos Authentication.
2. Click Test Connections.
The user directory is added. Note that you can modify the lookup order with the
exception of Locally Defined Users which is always the first entry on the list.

4.4.2 Create Kerberos Authentication in Centra
Creating Kerberos Authentication in Centra consists of three steps:
Step 1: Create a Keytab file.
Step 2: Configure Centra.
Step 3: Test the Configuration.
Step 1: Create a Keytab File
Creating a keytab file consists of the following procedures:
A. Create the user.
B. Create the keytab file.
A: Create the User
1. Create 'svc_guardicore' in the Active Directory.

2. Configure it to never expire and save the password for later, let's say the pass is "123456".

3. In User Settings, enable the following: `This account supports Kerberos AES 256 bit
encryption` and 'password never expires'.
B: Create the Keytab File
1. Open CMD (not powershell) on the AD server with admin privileges. Here is a quick review
of the syntax:

2. Execute the following command as an admin on the AD server `ktpass /princ

HTTP/centra@TESTING.GC /mapuser svc_guardicore@TESTING.GC /crypto
AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /pass 123456 /out c:\centra`
3. Move the Centra Keytab file created in the 'C:\' drive to a secure location.
4. If you want to read more on keytab, here's all you need to know about Keytab files.
Step 2: Configure Centra
1. Make sure you already have LDAP configured in the system as the permission group
membership check relies on the LDAP connection
2. Check the 'Enable Kerberos authentication' box:

Note: In our demo, the values in the above figure are replaced with the following:
Centra FQDN is centra.testing.gc
Realm is testing.gc

Keytab is the file that we saved in the previous section; upload it here. Once the file
uploads, the box turns green.
3. After you configure all the Kerberos details, it should look like this:


Note that the test connection button only tests the LDAP connection and not the Kerberos one.
Step 3: Test the Configuration
1. Make sure you have access to a user and an endpoint that are part of the domain. The user
should be part of a group in the AD that is allowed to access Centra.
2. While logged in with the domain user, open a Chrome browser and go to the Centra
address.
3. You should get signed in automatically.
4. If you get signed in automatically but want to use a different built-in user, simply log out
and use the alternative credentials.

4.4.3 Azure AD SAML 2.0 SSO

Configuring SAML 2.0 SSO with Azure AD for Centra involves the following:
Stage 1: Configure Azure AD SSO
Stage 2: In Centra, configure an AD Azure User Directory and User Permissions.
Stage 3: Finish the configuration in the Azure AD portal.
Stage 1: Configure Azure AD SSO
1. Sign into the Azure portal as a cloud application admin or application admin for your Azure
AD tenant.
2. Navigate to Azure Active Directory > Enterprise applications and select Centra from the
list. If a Guardicore application has not been created, create a new application (to add new
application, select New application).
3. Under the Manage section, select Single sign-on > SAML. The Set up Single Sign-On with
SAML - Preview page appears:

4. Select the Edit button to edit the parameters for Basic SAML Configuration:
5. Fill out the Basic SAML Configuration required fields as follows:
Field Value
Identifier (Entity ID) Enter your Centra URL, i.e https://centra.acme.org
Reply URL Enter Centra URL + /sso-authenticate - e.g.

https://centra.acme.org/sso-authenticate
6. After filling out the fields, click the Save button at the top of the dialog box.
7. Move on to the next step to set up User Attributes and Claims.

8. Click the Edit button at the top right of the dialog box and fill in the following fields:
Name user.mail
Note: If a user in the user@domain format has already been

configured manually in Centra, SAML authentication will fail
for that user and will default to local authentication.
MemberOf User.groups:
This attribute is used for checking permission scheme privileges.
Note:
If the number of groups the user is in exceeds a limit (150 for SAML,
200 for JWT) see the instructions at the end of this document..
UserEmail user.mail
9. Click Save and move to the next section, SAML Signing Certificate.
10. Click the Edit button and for the Certificate Signing Option, select Sign SAML response
and assertion, and click Save.
11. Download the SAML certificate by clicking the download link for Certificate
(Base64).
12. Copy the App Federation Metadata URL (the login url) for use at a later stage.
Stage 2: In Centra, configure an AD Azure User Directory

1. Login into Centra and in the Admin screen, access User Management/User Directories.
2. Click Add User Directory to display the Add New User Directory dialog
box:

3. Fill out the fields as follows:
Type SAML 2.0 SSO
Name Enter a friendly name that will help you identify this for your SSO setup.
Idp Entity ID The Azure AD identifier (Identifier Entity ID) under the Azure Configure
Sign-On page.
Note: If the Azure IdP entity ID contains a backslash character / at the end,
the UI prevents adding it. There is a workaround that requires changing the
entity ID in mongodb manually.
Idp SSO URL Paste the login URL (App Federation Metadata URL) that you copied in Stage
1, step 12 above.
Idp Certificate Open the certificate that you downloaded in Stage 1, step 11 above and copy its
contents. Then paste the contents into this field.

4. Click Verify Configuration and then click Save. The User Directory is listed on the User
Directory screen.
5. On the User Directory screen, select the User Directory that you just created and in the
User Directory box on the right, select the Key button at the top to download the
signing certificate. You will need to upload this to Azure AD.
6. Under User Management/Permission Schemes, add a new permission scheme.
7. Configure the options as you would like.
For Linked Directory Groups, select the SSO User Directory that you created and add the
value that you are looking to get for memberOf. For example if you entered groups, please
add the group name or ObjectID, etc. that you would expect to send to Centra.
Stage 3: Finishing the Configuration in Azure

1. Return to the Azure portal and select Token Encryption

2. Select Import Certificate and select the certificate file you downloaded from Centra.
3. Once imported, please select the ... on the certificate you uploaded and activate it.
4. Test login.

Configure a memberOf claim for SAML 2.0 SSO with Azure AD

These instructions provide a way to configure a memberOF claim when the number of groups the
user is in, exceeds the limit (150 for SAML).
To configure a memberOF claim:
1. Make sure you assigned the required groups to your Guardicore application in
Azure Active Directory. Use this link to assign groups to an application that is using
Azure AD.
2. Navigate to Azure Active Directory > Enterprise applications and select the
Guardicore application from the list.
3. Under the Manage section, select Single sign-on > SAML.
4. Select the Edit button to edit the claims parameters.
5. Click on Add a group claim
6. Select the Groups assigned to the application in the Group Claims options:

7. Choose the sAMAccountName option in the Source attribute drop down list.

8. Check the Advanced Options and provide the name memberOf
9. Save the changes

4.4.4 OKTA SAML 2.0 SSO
Configuring SAML 2.0 with Okta comprises 3 steps:
Step 1: Configure the Okta Guardicore app
Step 2: Configure the user directory in Centra
Step 3: Configure the Okta group in Centra
Note: Step 1 is redundant once the Guardicore app is accepted into the Okta application directory.
Step 1: Configure the Okta Guardicore App
1. In the Okta classic UI, select Applications and click the Add Application button:
2. Click Create New App and in the Create a New Integration dialog box, specify the
following:
Platform: Web

Sign on method: SAML 2.0:
3. Click Create and under General Settings, for App Name, specify Guardicore:

4. Click Next and fill in the fields as follows:
Field Specify this:
Single Sign on URL This should be the URL to the Centra system as the client sees it
concatenated with the SAML authentication REST endpoint. For example,
for GC-MGMT it's
'https://cus-1801.cloud.guardicore.com/sso-authenticate'.
So the pattern is 'https://{Centra URL}/sso-authenticate'
● Select 'Use this for Recipient URL and Destination URL'
Audience URI (SP Entity ID) The Centra URL. For example for GC-MGMT:
'https://cus-1801.cloud.guardicore.com'

DefaultRelay State Leave empty
Name ID format Select EmailAddress
Application User Name Email
5. Click Advanced Settings and fill in the fields as in the following:
6. Fill in Attribute Statements (Optional) as follows:

Add one attribute named 'userEmail' with Name format set to 'Basic'. Value should be
'user.email'. The attribute name 'userEmail' is case sensitive so make sure you are
writing it exactly as shown.
Note: If a user in the user@domain format has already been configured manually in
Centra, SAML authentication will fail for that user and will default to local
authentication.
7. Fill in Group Attribute Statements (Optional):
Add one attribute name 'memberOf' with name format set to 'Basic'. Filter should be
selected to 'Matches regex' and value '.*' (dot and asterisk). 'memberOf 'is case
sensitive:

8. Click Next to finish the Application configuration phase:
9. Click on the Application and navigate to the Sign On tab:

10. Click on View Setup Instructions to open a new page with the SAML details. You will need
to copy some of these details for Step 2 that follows.
Step 2: Configure the User Directory in Centra
1. Click on the newly created Okta Guardicore application and navigate to the 'Sign-On' tab.
2. In Centra's Admin screen, select User Management, User Directories to display the Add
New User Directory dialog box:

3. Fill in the fields as follows:
Field Specify this:
Type SAML 2.0 SSO
Friendly Name Okta
Idp Entity ID Copy from the Okta instruction page.

(Identity Provider Issuer)
Idp SSO Copy from the Okta instruction page.

(Identity Provider Single Sign-On URL)
Idp Certificate Copy from the Okta instruction page.

(X.509 Certificate)
4. Add the assertion signing key to Okta:

a. In the User Directories screen, click the provider (Okta) to display User
Directory Details and a Key button:
b. Click the Key button to download a PEM file.
5. Return to the Okta UI and click the Edit for SAML settings under the Centra app.

6. Under Advanced Settings, in the Encryption Certificate box, click the Browse button and
upload the PEM file.

The connection between Okta and Centra is now configured.
Step 3: Configure the Okta group in Centra
This step enables configuring the actual users. In the following instructions we will configure Okta
users, but in a real use case it could also be a user that is synced from an internal AD. All that
matters is that the group is configured correctly.
1. In the Okta UI, click Directory/Groups, and click the Add Group button to add a new group
(in this example, GC):

2. Click the group and associate users with it. In this example, a user named Test was
associated with the group.

3. In Centra, select Admin/User Management/Permission Schemes, select a Permission

Scheme and add the name of the group in the Linked Directory Groups box:
Note: Make sure you type the name correctly, as there is no validation feedback on this field.
4. In the logon screen, run the SAML login flow.

4.4.5 Red Hat SAML 2.0 SSO
This article provides instructions on how to configure SAML 2.0 for Guardicore Centra in the
Red Hat environment. The instructions comprise four stages:
Stage 1: Configure the IdP
Stage 2: Configure the Service Provider
Stage 3: Configure the Encryption Key
Stage 4: Configure the Permission Scheme in Centra
Stage 1: Configure the Identity Provider (IdP)
1. Sign into the RH-SSO admin console.
2. Make sure you are in the relevant realm that contains the users for the Centra
integration.
3. In the Master menu, under Configure, choose Clients and click the Create button:
The Add Client dialog box appears:

4. In the Add Client dialog box, add Guardicore as a client as follows:

a. Client ID - Enter the Centra URL – e.g. https://centra.acme.org.
b. Client Protocol - Select SAML.
c. In the Root URL (Client SAML Endpoint), enter the Centra URL +
/sso-authenticate – e.g. https://centra.acme.org/sso-authenticate.
d. Click Save. A dialog box describing the new SAML client appears:

5. On the Settings tab, fill in the fields as follows:
Field Value
Name A friendly name for the client
Enabled On
Include AuthnStatement On
Sign Documents On
Sign Assertions On
Signature Algorithm SHA256

SAML Signature Key Name CERT_SUBJECT
Canonicalization Method Exclusive
Encrypt Assertions On
Client Signature Required On
Force POST Binding On
Front Channel Logout OFF
Force Name ID Format OFF
Name ID Format email
Valid Redirect URLs The client SAML endpoint (in this example,
http://centra.acme.org/sso-authenticate)
Base URL For example, https://centra.acme.org
Master SAML Processing URL The client SAML endpoint (in this example,
http://centra.acme.org/sso-authenticate)
6. Select the Roles tab and make sure no roles are assigned to this client.
7. Select the Client Scopes tab and make sure no roles are assigned to this client.
8. Select the Mappers tab and click Create to display the Create Protocol Mapper dialog
box:

9. In the Create Protocol Mapper dialog box, fill in the fields as follows:
Field Value
Name memberOf
Mapper Type Group list
Group attribute name memberOf
Friendly Name memberOf
SAML Attribute ON
NameFormat
Single Group Attribute ON
Full Group Path OFF
10. Click Save to save the data and return to the Mappers tab.
11. On the Mappers tab, select the add builtin button to display the Add Builtin Protocol
Mapper dialog box:

12. In the Add Builtin Protocol Mapper dialog box, select x.500 email mapper and click the
Add selected button.
13. On the Mappers tab, edit the x.500 email mapper as follows:
a. Change the friendly name to UserEmail.
Note: If a user in the user@domain format has already been configured

manually in Centra, SAML authentication will fail for that user and will
default to local authentication.
b. Change the SAML Attribute Name to UserEmail.
c. Set SAML Attribute NameFormat to Basic.

14. Click Save.
15. On the Installation tab, in the Format Option list, select SAML Metadata
IDPSSODescriptor:

16. Click the Download button to save the xml to a file. ▲
Stage 2: Configure the Service Provider
SAML Directory Configuration:
1. Log in as a global administrator to the Centra system.
2. Navigate to the Administration page.
3. Access User Administration>User Management>User Directories.
4. Add a new user directory.
5. Select SAML 2.0 SSO.

6. Idp Entity ID: copy the entityID url from the EntityDescriptor section in the xml from the
previous section.
7. Idp SSO URL: copy the SingleSignOnService Location URL from the
SingleSignOnService section in the xml from the previous section.
8. Idp Certificate: copy the certificate from the dsig:X509Certificate section in the xml from
the previous section.
9. Click Verify.
10. Click Save.
Stage 3: Configure the Encryption Key
1. Click on the newly created entry; a pane should appear on the right.
2. Click the Key icon to download the public key for assertion encryption configuration:
3. Open the RH SSO console and select the clients SAML Keys tab.
4. Click Import under the Encryption Key section and import the PEM file downloaded from
the Centra system.
5. Click Import under the Signing Key section and import the PEM file downloaded from the
Centra system.

6. 4.4.6 FortiAuthenticator SAML 2.0

FortiAuthenticator provides secure access and identity management for Fortinet enabled
enterprise networks. This article provides instructions on how to configure FortiAuthenticator
SAML 2.0 with Guardicore Centra.
Instructions for configuring Guardicore Centra as an SP for FortiAuthenticator are standard and
provided below. However, there are two additional “non-standard” settings that must be
configured by Guardicore Support:
In case the IdP entity ID contains a slash character:

If the IdP entity ID contains a slash character / at the end, the UI prevents adding it.
Therefore, this requires manually changing the entity ID in Centra’s configuration

database. Contact Guardicore Support.
Deactivate Guardicore’s encrypted assertion requirement

By default, Guardicore Centra works only with encrypted assertions. However, currently,
FortiAuthenticator does not support encrypted assertions. Although there are certificate
options in the FortiAuthenticator configuration that support certificate use for encryption,
they do not currently support SAML payload encryption as expected. We are aware that
there is a feature request open with FortiNet to rectify this situation.
Therefore, in the meantime, you must contact Guardicore Support to deactivate the
requirement for encrypted assertions. Please open a support ticket and be sure to
indicate that you are using FortiAuthenticator for SSO/SAML and that you require an
encrypt assertion override.
Configuring FortiAuthenticator requires the following stages:
Stage 1: In FortiAuthenticator, configure IdP settings.
Stage 2: In Centra, configure a User Directory for FortiAuthenticator.
Instructions for each stage are provided below.

Stage 1: Configure SSO and IdP settings in FortiAuthenticator

1. In FortiAuthenticator, configure SAML Authentication settings using the
FortiAuthenticator wizard.
2. For general IdP settings,enable the SAML identity provider portal and enter the following:
a. Server address: Enter the FortiAuthenticator FQDN.
b. Realms: Add the realm associated with the remote server for G Suite.
c. Default IdP certificate: Select a default certificate to use.
d. Click OK to save the settings.
3. Configure Guardicore as a service provider as follows:
a. From Authentication > SAML IdP > Service Providers create a name (for example,
Guardicore) for the service provider (Guardicore) that you will use as a SAML client.
b. Enter the SP information from the client you will use as the SAML service provider
(enter the Centra URL that you are using).
c. Download the IdP metadata.

This can be used to set up the SAML IdP configuration in your SAML SP client (i.e. in
Guardicore Centra).
d. Under SAML Attribute click Create New, and enter a SAML Attribute name that
your SAML SP is expecting to identify the user. Select a User Attribute for this
selection. If you're unsure of which attribute to pick, select SAML Username.
e. Click OK to save your settings.
f. Access Guardicore Centra to proceed to the next stage.

Stage 2: In Centra, configure a User Directory for FortiAuthenticator

1. On the Centra Administration screen, access User Management/User Directories:
2. Click + Add User Directory to display the Add New User Directory dialog box:

3. Fill out the fields as follows:
Type SAML 2.0 SSO
Name Enter a friendly name that will help you identify this for your SSO setup.
Idp Entity ID The FortiAuthenticator Identifier (your Centra URL i.e

https://centra.acme.org) that you entered in Stage 1.
Note: If the IdP entity ID contains a slash character / at the end, the
UI prevents adding it. Contact Guardicore Support to manually
change the entity ID in Centra’s configuration database.
Idp SSO URL Paste the login URL that you entered from the previous stage.
Idp Certificate Open the certificate from the IdP metadata that you downloaded from
Stage 1 and paste the contents into this field.

4. Click Verify Configuration and then click Save. The User Directory is listed on the User
Directory screen.
5. Under User Management/Permission Schemes, add a new permission scheme.
6. Configure the options as you would like.

4.4.7 Permission Schemes
Permission Schemes enables administrators to restrict a user's access to Reveal maps, Incidents,
and Neighboring Assets. Administrators can assign scoped permissions such as View Reveal Maps
or View Incidents. For example, some application owners might be allowed to view all data
pertaining to their application (with all other applications hidden) while some site owners might be
allowed to access only Reveal maps pertaining to their environment.
Why Create Permissions?
Some of the reasons for creating permission schemes include the following:
● Limit users' view based on asset labels, e.g. service providers may want to provide their
customers access to the information related to their assets only.
● Allow each user to view a limited scope of Centra:
- Reveal Map of user's related assets
- Security incidents related to the user's assets
Create a Permission Scheme
To create a Permission Scheme for a user:
1. From User Management select Permission Schemes.
2. Click and complete the fields in the following screen:

The following table provides information on each field:
Field Description
Title The title of the Permission Scheme
Description A short description of the scheme
Role A role is a set of permissions and related allowed actions. The following roles are
available:

Role and Description Global/Custom

Associated Permission
Permissions
Global Provides full access to, Global

Administrator and configuration of, all
(Full Control) system data
Guest Provides read Global

(View All) permissions to all
system data except for
Audit Log and Users
data
Incidents Viewer View incidents only Custom

(View Incidents)
Reveal Map Access Reveal maps Custom

Viewer (Explore only
Reveal Data)
System Custom
Administrator
Application Manage segmentation

Owner policy of application
Prevent override The checkbox is available for the Application Owner role only. Selecting the
rules creation or checkbox prevents anyone with the Application Owner role to create or edit
modification Override rules. Override rules appear as read only to the Application Owner.
checkbox
Scope by Labels Defines the scope of the permission, based on labels.
Default View The first Centra screen the user sees after login based on the defined permission.

Linked Directory Attach custom permission schemes to Active Directory groups. Make sure you
Groups activate the User Directories feature before you activate the new AD groups in
the Linked Directory Groups field.
3. Click Save. The Permission Scheme is displayed in the list of Permission Schemes:
4. Clicking a Permission Scheme in the list displays the scheme's details in the right pane and
enables you to edit the scheme:

Roles Based Permissions to Centra's Features
The following table provides details on the default role permissions to Centra's features.
Title Action Global Guest System Global Policy Applicatio Reveal Incidents
Admin Admin Administrator n Owner Map Viewer
Viewer
Dashboard View ✓ ✓ ✓ ✓
Network View ✓ ✓ ✓ ✓
Statistics
Reveal>Explore Explore ✓ ✓ ✓ ✓ ✓ ✓ ✓
and Saved Maps
Create ✓ ✓ ✓ ✓ ✓ ✓
Delete ✓ ✓ ✓ ✓ ✓
Label ✓ ✓
asset
Set map ✓ ✓ ✓ ✓ ✓ ✓
default
view
Explore ✓ ✓ ✓
Precomp
uted
Explore ✓ ✓
Private
Explore ✓ ✓ ✓ ✓
All
Scoped

Create ✓ ✓
Private
Reveal>Labels View ✓ ✓ ✓ ✓ ✓
labels
Add label ✓ ✓
Delete ✓ ✓
label
Edit label ✓ ✓
Policy>Create Edit & ✓ ✓

Policy Publish
Policy>Projects View ✓ ✓ ✓ ✓
Edit ✓ ✓
Policy>Rules View ✓ ✓ ✓ ✓ ✓
Publish ✓ ✓
changes
Discard ✓ ✓ ✓
changes
Suggest ✓ ✓ ✓
changes
Policy>Revisions View ✓ ✓ ✓ ✓ ✓
Revert ✓ ✓
policy

Policy>Label ✓ ✓
Groups
Policy>User View ✓ ✓ ✓ ✓
Groups
Edit ✓ ✓
Publish ✓ ✓
changes
Discard ✓ ✓
changes
Incidents + View ✓ ✓ ✓ ✓ ✓ ✓
Incident Groups
Edit ✓ ✓ ✓
Assets View ✓ ✓ ✓ ✓ ✓
Edit ✓ ✓
Activity>Networ View ✓ ✓ ✓ ✓ ✓
k Log
Activity>Redirec View ✓ ✓ ✓ ✓ ✓
tion Log
Activity>Reputat View ✓ ✓ ✓ ✓ ✓
ion Log
Activity>Integrit View ✓ ✓ ✓ ✓
y Log
Activity>Label View ✓ ✓ ✓ ✓
Log
Inspection policy View ✓ ✓ ✓ ✓

Edit ✓
Detection>Detec View ✓ ✓ ✓ ✓
tors
Edit ✓
Detection>Reput View ✓ ✓ ✓ ✓
ation
Edit ✓
Integrity View ✓ ✓ ✓ ✓
Monitoring>Tem
plates
Publish ✓
changes
Discard ✓
changes
Suggest ✓
changes
Cleanup ✓
stale
hashes
Mitigation & View ✓ ✓ ✓ ✓

IOCs
Edit ✓
Components>De View ✓ ✓ ✓
ception Servers
Edit ✓ ✓
Components>Col View ✓ ✓ ✓
lectors
Edit ✓ ✓

Components>Ag View ✓ ✓ ✓
gregators
Edit ✓ ✓
Agents>Agents View ✓ ✓ ✓ ✓
Edit ✓ ✓
Agents>Agent View ✓ ✓ ✓
Installation
Screen
Agents>Agents View ✓ ✓ ✓
Log
Agents>Agent View ✓ ✓ ✓ ✓
installation
profiles
Edit ✓ ✓
Data View ✓ ✓ ✓
Center>Orchestr
ations
Edit ✓ ✓
View ✓ ✓ ✓
Data View ✓ ✓ ✓
Center>Orchestr
ations
Integration View ✓ ✓ ✓
Edit ✓ ✓
User View ✓ ✓
Management>Us
ers
User View ✓ ✓ ✓
Management>Us
er Directories

Edit ✓ ✓
User View ✓ ✓
Management>Pe
rmission
Schemes
Edit ✓ ✓
System>Log View ✓ ✓ ✓
System>Configur View ✓ ✓ ✓
ation
Edit ✓ ✓
System>Info View ✓ ✓
System Auditing View ✓ ✓
System Repo Key Edit ✓ ✓
Scoped Application Owner Role
V31 introduces a new role into the system – Application Owner. The role allows you to define
configuration access only to a specific scope of assets. Scoping in v31 enables users to create and
edit segmentation rules within a particular scope. The scope for creating and editing these rules is
determined by the labels that have been defined within the user’s scope in the user’s assigned
Permission Scheme. Scoping of Segmentation Rules adheres to the following restrictions:
● Application owners can create new rules that include the scoped labels but cannot publish
the rules. The rules can be reviewed and published by the Administrator or Global Policy
Admin.
● Application owners cannot revert policy.
● Application owners can only discard the changes in the context of their own changes and
cannot affect changes in other user’s contexts.

● Application owners will see unpublished rules only in their scope but will not see
unpublished rules in other user’s scopes unless the unpublished rule directly affects any of
the scoped rules.
● All other aspects of scoping such as scoping for Reveal maps and the ability to view
incidents, assets, activity logs, FIM policy, etc. are as in previous versions.
Assign a Permission Scheme to a User
To assign a permission scheme to a user:
1. From System, select Users and in the Add New User dialog box, fill in the Username, Email
Address and Description fields.
2. In the Permission Scheme field, scroll through the list of Permission Schemes and select the
scheme that you want to assign to the user.

3. Fill out the remaining fields and click Save.

4.5 Centra Additional Configurations

4.5.1 KO Cloud Connection
Background
This article contains instructions for connecting a Centra Management to Guardicore’s KO Cloud.
The KO Cloud is a hosted environment that contains the gc_enforcement kernel modules for all
supported Linux distributions for all existing and supported kernel versions.
This article is relevant for on-premises deployments, as SaaS deployments are automatically
connected to the KO Cloud.
In case the matching KO file is not found on the management or on the KO Cloud - a rare situation
typically associated with custom-built kernels which are not available on public repositories - the
Agent will move to “polling mode” and will provide limited Reveal service. A flag will be raised in
Management so the issue can be detected by the administrator and handled with Guardicore
support. When the supported KOs are added locally to Management and/or to the KO Cloud and
through it to Management and Aggregators, the wrapper automatically detects the added KOs
and installs them and the Agent returns to its normal operation without any need for operator
involvement.
Preparation/Prerequisites
1. Receive a token.json file from Guardicore.
2. Configure permissions on the Management:
chown -R guardicore-svc:guardicore-svc /storage/kos/
chmod 755 /storage/kos/store
chmod 777 /storage/kos/cache
chmod 644 /storage/kos/store/*

chmod 755 /storage/kos/store/default

chmod 777 /storage/kos/cache/default
chmod 644 /storage/kos/store/default/*
chmod 755 -R /storage/kos/cache/default/*
Steps
1. Copy the token.json received from Guardicore onto the Management in the path
/etc/guardicore/ko_cloud/token.json
2. Edit `/etc/guardicore/ko_cloud/major_versions.csv` with the relevant versions for said
customer. For example:
36,37
3. Enable the ko-cloud configuration by running the following command:
gc-ko-cli configure --sleep-interval-seconds 3600 --bucket-name ko-cloud-bucket --enable
a. To add proxy support, also specify proxy URL (GA since v32):
gc-ko-cli configure --sleep-interval-seconds 3600 --bucket-name ko-cloud-bucket
--enable --proxy-url https://<proxy_url>
*GCP bucket accepts only https proxy, if your proxy is an http proxy please set it in the
command like: https_proxy=http://URL:PORT
4. Check KO-cloud status by running:
gc-ko-cli status
5. Validate that sqsh files are updating under `/storage/kos/store/default`
6. In order to manually fetch new KOs, run the following command:
gc-ko-cli fetch

4.5.2 Monitoring Relay For On-Prem Customers

For SaaS customers, monitoring of the client’s environment health is being achieved via the
Grafana platform, incorporating various metrics and alerts to be handled.
For on-prem customers, a relay to Guardicore’s Grafana system can be configured in order to
connect the client’s environment and supply monitoring service. The following article describes
this procedure.
Make a request to monitor an on-prem environment via Grafana

monitoring service:
1. Supply the customer’s environment name.
2. Supply the customer’s external IP address, to be allowed in the GC Grafana system.
After creation, receive the aforementioned parameters

1. Copy the supplied parameters to following file:
/etc/guardicore/external_monitoring/output_external_monitoring.conf
2. The parameters should look like (parameters substituted with actual credentials):
database = "<environment name>"
username= "<username>"
password = "<password>"
# DO NOT EDIT THESE

ssl_ca = "<masked>"
retention_policy = "<masked>"
write_consistency = "<masked>"
timeout = "<masked>"
Restart the Telegraf-Relay service

gc-cluster-cli service-restart --service_name telegraf-relay

4.5.3 Disaster Recovery
Unplanned incidents can happen at any time. Your network could suffer connectivity problems,
the hypervisor that hosts your system components can crash, or your entire site might fail. When
things don’t go as planned, it’s important to have a well-planned disaster recovery solution that
ensures continuous system operation at all times. Guardicore’s disaster recovery approach allows
for continuous system operation in times of complete site failure, connectivity problems,
hypervisor crash, etc.
Note: The described solution is relevant for on-premises deployments only, as availability of SaaS
deployments is guaranteed by Guardicore.
Guardicore’s Disaster Recovery Solution: How it Works
Guardicore’s solution comprises two different management clusters:
● the primary cluster that is designed to be the active management

● the standby cluster that acts as backup in case the primary cluster fails.
Both clusters can be active or backup, but only one can be active or backup at any given time. If the
primary cluster fails, you can initiate a failover on the standby cluster to continue system
operations on the standby cluster. When the primary cluster becomes available, it returns to
active and the standby cluster goes back to being the backup cluster.
Centra ensures there is an ongoing sync between the two clusters. For example, all segmentation
rules and labels written to the primary cluster are replicated to the backup cluster, and the other
way around.
What's synced
● Configuration (information)
● Inventory (list of assets, aggregators etc’)
● Segmentation policy

What's not synced
● Reveal data
● Incidents data
Instructions for Configuring the System for Disaster Recovery
Before you can initiate a failover, you must first configure the system so that it is capable of
switching between a primary management cluster and a secondary management cluster.
1. Install two different management clusters. These are referred to as Primary Management
Master/Cluster and Standby Management Master/Cluster.
2. Allow SSH communication between the management master within each cluster (i.e. by
doing ssh-copy-id <standby-IP>).
a. Perform on standby also: ssh-copy-id <primary-IP>
3. Sync the certificates between the primary management master and the standby
management master:
Add the following in /etc/guardicore/hosts at the end of the file on the primary:
1 ...
2 [peer_master]
3] [standby_master_ip]
4. To synchronize the certificates, run the following on the primary management cluster:
gc-dr-cli sync-standby-certs
This copies all certificates from the primary management master to the standby one.
5. Configure the primary management cluster:

Run the following on the primary:
gc-dr-cli configure --current-role primary --primary-ip <my-ip>

--standby-ip <standby-ip> --components-standby-ip
<component-facing-standby-ip> --components-primary-ip
<component-facing-primary-ip> --sleep-interval-seconds 360
Notes:
● components-standby-ip and components-primary-ip should be

different then standby-ip and primary-ip in case the component facing
subnet differs from the inter-management subnet.
● sleep-interval-seconds determines the interval between the collection
of configuration to be fetched by the standby in order to keep them
synchronized.
6. Enable the primary management cluster by running the following on the primary:
gc-dr-cli enable
7. Configure the Standby management cluster on the standby:
gc-dr-cli configure --current-role standby --primary-ip

<primary-ip> --standby-ip <my-ip> --components-standby-ip
<component-facing-standby-ip> --components-primary-ip
<component-facing-primary-ip> --sleep-interval-seconds 360
Note:
sleep-interval-seconds determines the interval between each time the standby management
cluster attempts to fetch the new backup configuration.
8. Enable the standby management cluster by running the following on the standby:
gc-dr-cli enable

9. Verify the configurations:
To verify the Standby configuration:
● On the designated standby management master, run gc-dr-cli status; something

like the following should appear:
Management ID State Role
ae4a51b3bd5a511a82de080255e6b07b Backup Standby
To verify the Primary configuration:
● On the designated primary management master, run gc-dr-cli status;

something like the following should appear:
Management ID State Role
ae4a51b3bd5a511a82de080255e6b07b Active Primary
Initiating Failover
In case the primary cluster fails for any reason, the administrator can initiate the failover. This will
cause the standby management cluster to take over as the primary management cluster. All
management operations will then be available on the new active cluster.
To initiate the failover, perform the following:

1. Run the following on the standby management master: gc-dr-cli failover
The following prompt appears:
Warning: You are about the initiate DR sequence

Are you sure you want to continue? [y/N]
2. Type y to initiate the failover.
The process takes around 10 minutes, including the shifting of the components to the standby
management master which now acts as the primary management master.
Instructions for Performing a Failback
Once the disaster has been resolved and the designated primary cluster regains availability, the
administrator can initiate the failback process. All configuration and policy changes made to the
standby cluster during the disaster period will be synced back to the primary cluster.
1. To initiate the failback and return the system to the primary cluster, run the following on
the standby:
gc-dr-cli generate-config
This triggers unscheduled configuration collection and archiving to speed up the

failback process.
2. Initiate fetch and load configuration from the designated standby (current "active"
management). Run the following on the primary management master:
gc-dr-cli pull-and-load-config
The designated primary management master will now pull the file created on the standby
management master and load it. The designated primary management master is now ready for
use.
Return the standby management master to its original standby role by running the following on
the standby management master:

gc-dr-cli standby
The designated standby is stopped, and the primary management cluster becomes the active one.
This returns us to the original state: the designated master cluster is the "active" cluster, while the
designated standby cluster is the "backup" one.
Failback to New Primary
Use this procedure if the old primary management cluster is gone or non-recoverable.
Preliminary steps
Deploy a new primary management cluster with the same control node IP address as the previous
primary control node.
Failback Steps
Step 1: Shut Down the Primary Cluster
● On the new primary control node run:
gc-cluster-cli cluster-stop --group all
Step 2: Allow SSH Between the Two Clusters
1. Copy SSH keys from management primary to standby node by running
ssh-copy-id <standby-IP>
2. Copy SSH keys from management standby to primary node by running
ssh-copy-id <primary-IP>
Step 3: Sync Certificates

You must now sync the certificates between the primary management control node and the
standby management control node. To this perform the following steps:

1. On the primary, in the file /etc/guardicore/hosts, at the bottom of the file, add the
following:
...
[peer_master]
<standby_control_node_ip>
Note: You do not need to do this on the standby as it should already be present.
2. Backup /var/lib/guardicore/storage/certs/tls on the new primary control node.

3. Copy all of the subdirs from the standby under /var/lib/guardicore/storage/certs/tls to the
new primary control node (this must be done manually as there is currently no script for
this)::
- "aggregator"
- "disaster_recovery"
- "disaster_recovery_server"
- "gcca"
- "mesos_master"
- "mitigation_ca"
- "mongodbclient"
- "mongodbserver"
- "mitigation_cas_chain.pem"
- "rabbitmq"
- "rabbitmqserver"
- "remote_ssl_proxy"
- "remote_ssl_proxy_server"

4. Run the following on the new primary control node
gc-dr-cli propograte-certificates
5. Restart dr-ssl-proxy
gc-cluster-cli infra-service-restart --infra_name dr_ssl_proxy
6. On the new primary run to load the new certificates
gc-cluster-cli infra-service-start --infra_name dr_ssl_proxy
Step 4: Configure the New Primary
Configure the new primary as instructed in the Instructions for Configuring the System for
Disaster Recovery section. No need to re-configure the standby.
Step 5: Enable Disaster Recovery
Now that the primary disaster recovery settings have been configured, enable it by running the
following on the standby:
gc-dr-cli enable
Step 6: Pull and Load the Configuration from the Standby

To initiate fetch and load configuration from the designated standby (current "active"
management), run the following on the new primary management control node:
gc-dr-cli pull-and-load-config
Step 7: Turn the Standby to Standby Mode
On the standby control node run:
gc-dr-cli standby

4.5.4 Centra Plugins Server Installation

Centra Plugins provide optional tools that expand Centra's capabilities. Some tools provide
integration to other security management systems and enable you to import data into Centra, or
conversely to export data and policy rules from Centra to other systems. Other tools enhance
Centra's features and the connections between them.
In order to activate the plugins, first we need to install the plugin server.
Steps
1. Contact Guardicore support team and receive the Plugins Server OVA, and deploy in the
environment.
2. Connect to the Plugins Server using the temporary root password: GCAdmin123
3. Configure the interface of the machine:
a. To set it to using DHCP:
gc-plugins-server configure_interface --set_dhcp
b. To configure a static IP:
gc-plugins-server configure_interface --ip <ip/CIDR> --gw
<gateway IP> --dns <comma-separated list of dns servers>I
4. Configure the REST API username/password:
a. To create a new user go to Centra -> Administration -> Users and click on Add User
i. Create an admin user
b. Configure the plugin server with the username/password that were just created
and the management server FQDN/IP:

gc-plugins-server set_credentials --type centra_rest_api

--ip <mgmt server IP/FQDN[:port]> --username <REST API user>
--password <REST API password>
5. Configure the API key & customer ID:
a. Run the following commands on the Centra Management Server, copy the output
and send them to support@guardicore.com to receive your key:
i. Collect the customer ID:
gc-mgmtctl get_conf --group management --option
installation_id
ii. Collect the plugins API key:
gc-mgmtctl get_conf --group management --option
plugins_api_key
b. On the plugins server, once receiving the API key from Guardicore Support,insert
the generated key:
gc-plugins-server set_credentials --type customer_info --id
<customer ID> --api_key <generated API key>
6. Configure the username/password/token for the Inventory API Orchestration:
a. To set up the inventory API Orchestration see - Inventory API Orchestration.
gc-plugins-server set_credentials --type inventory_api
--aggr_ip <IP/FQDN of the aggregator[:port]> --username
<username for the Inventory API or ""> --password <password
for the Invenotry API or ""> --token <token for the
Inventory API or "">
7. Restart the plugins server:
supervisorctl restart gc-plugins-server
8. Register the plugins
gc-plugins-server register_all_ga_plugins --overwrite True
9. Change the root password of the machine
passwd root

10. To view the plugins go to the admin panel -> Plugins

5 Appendices
5.1 Appendix A: Agents and OS Support
For updated OS support for Guardicore agents and OS, refer to this link.
Fur further information regarding support for your Centa version, contact your Guardicore
engineer.

5.2 Appendix B: Management Service Pack

update
After the management cluster deployment, contact Guardicore Professional Services for the
latest “Service Pack” update. The Service Pack includes minor updates, versions and updates
bundled together. This service pack is to be applied after the initial deployment of Centra, as these
packs are distributed recurrently as part of the R&D effort towards answering upcoming issues
between big versions / patch updates.
The installation process is as follows:
1. Upload the 2 hotfix files to /tmp on management
2. Apply Code Hotfix
a. gc-auto-hotfix /tmp/MG-350310.tar.gz
3. Apply Dist Hotfix
a. gc-auto-hotfix /tmp/MG-350311.tar.gz
4. Restart the services
a. gc-cluster-cli cluster-restart --group app
b. gc-cluster-cli service-restart --service_name nginx
5. After the application of the Service Pack, verify proper application in the following sources:
a. /etc/guardicore/hotfixes_bookkeeping
b. /var/log/guardicore/gc-hotfix.log
c. Version and build updated in the management info pane:

5.3 Appendix C: Security Package Upgrade

The security package contains the latest security updates for the Bionic (18.04) Ubuntu release.
The content of the package is pulled from Index of /ubuntu/dists/bionic-security at creation time.
The package is based on the difference between a clean Ubuntu release in

build_v30_20190625_40 and now.
Subject to testing, it should be compatible with any release after build_v30_20190625_40.
Prerequisite
● Verify with the client that no other packages were installed on the management host,
such as additional user agents, etc.
● Contact Guardicore PS team to create a new package.
● Download the package and obtain the 2 files:
○ gc_bionic_security_package_<datetime>.tar- A file containing the deb
packages that will be installed.
○ Apply_security_package.sh- A script file that applies the patch.
Procedure
● Create a snapshot of each node of the management cluster.
● Stop the cluster, including all pipelines and infra:
○ gc-cluster-cli cluster-stop --group all
○ gc-cluster-cli cluster-stop --group proxy
● Verify that the Management node has sufficient disk space and select a target directory.
Note: You need space of about twice the size of the patch: one space for downloading the
patch and another for extracting it.
● Copy the .tar file and the script to the target directory (/storage is recommended).

● Use gc-mgmtctl copy_file_to_remote_nodes --file_path_to_copy

<file_name> to distribute the patch and script to all nodes.
● Run apply_security_package.sh -f
gc_bionic_security_package_<datetime>.tar -t /tmp/apt_repo.
Note: Make sure /tmp has enough disk space (roughly the size of the patch) or select a
different directory for extraction.
● The script will extract the contents of the .tar file to /tmp/apt_repo, and will start a “dry
run” of installing the updates. After the dry run, the script will prompt if you would like to
continue and actually apply the updates.
● Verify there are no errors in the dry run output before proceeding
● To proceed, enter Y in the dialogue.
● When the patch is finished, a restart to the node may be required. Check the output log for
the message - ********* Reboot node to finish upgrade! *********
● Repeat the apply_security_package.sh step (step 6 above) for each Management
node.
● Start the cluster:
○ gc-cluster-cli cluster-start --group proxy
○ gc-cluster-cli cluster-start --group all

Akamai Guardicore Segmentation Installation Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Akamai Guardicore Segmentation Installation Guide

Uploaded by

Copyright:

Available Formats

Centra 5.

0.1 Table of Contents

0.2 Revisions Record 14

0.3 Revisions Highlights 15

0.4 Supported infrastructure 16

Guardicore Centra Security Platform 17

About this Manual 17

1.1 Centra Architecture 19

1.2 Deployment Overview 20

1.3 Deployment Preparations 22

2.1 Vmware installation 32

© 2021 Guardicore LTD. | 2

Proprietary and Confidential

Conﬁgure RabbitMQ Redundancy Cluster 58

© 2021 Guardicore LTD. | 3

Proprietary and Confidential

Mega Aggregators 119

2.2 AWS Centra installation 121

2.3 Hyper-V installation 151

© 2021 Guardicore LTD. | 4

Proprietary and Confidential

Conﬁgure MongoDB HA Cluster 193

2.4 Azure installation 213

2.5 GCP Installation 238

© 2021 Guardicore LTD. | 5

Proprietary and Confidential

2.6 OCI Installation 248

3.1 Overview of Agent Installation Steps 259

3.2 Checks to Perform BEFORE Deployment 260

3.3 Manual Deployment of Agents Using the Admin GUI 269

3.4 Introduction to Agent Installation 272

3.5 Windows Agents Installation 272

© 2021 Guardicore LTD. | 6

Proprietary and Confidential

Windows Agent - Dependency Packages 276

3.6 Linux Agents Installation 283

3.7 AIX Agent Installation 291

© 2021 Guardicore LTD. | 7

Proprietary and Confidential

Online installation using wget 294

3.8 Solaris Agent Installation 297

3.9 Docker Native Agent Conﬁguration 306

3.10 Kubernetes Deployment 307

© 2021 Guardicore LTD. | 8

Proprietary and Confidential

Known Issues: 308

3.11 Automatic Agent Deployment 321

3.12 Agent Deployment Veriﬁcation 323

3.13 Installing Agent Log Rotation Proﬁles 328

4.1 Orchestrations 330

© 2021 Guardicore LTD. | 9

Proprietary and Confidential

© 2021 Guardicore LTD. | 10

Proprietary and Confidential

Step 2: Conﬁgure OpenStack Orchestration in Centra 347

4.2 Exportables Conﬁguration 369

4.3 Integrations 384

© 2021 Guardicore LTD. | 11

Proprietary and Confidential

How It Works 385

4.4 Authentication And User Management Conﬁguration 394

© 2021 Guardicore LTD. | 12

Proprietary and Confidential

Assign a Permission Scheme to a User 451