To bootstrap the tunnel, the Secure Connector client creates a public or private key pair and signs its public key certificate remotely by the server. A cryptographic single-use time-limited token is used to secure this remote signing process and identify the root scope to which the client belongs. On the server side, each root scope has a unique certificate that the client uses to authenticate the server. These certificates are periodically rotated to ensure the continued secrecy of communication.

The Secure Connector client is internally constructed of a tunnel client and a SOCKS5 server. After the tunnel is started, the client waits for incoming tunnelling connections from the Secure Workload Cluster. Incoming connections are handled by the SOCKS5 server and forwarded to the destination host.

The following are the requirements for the Secure Connector client:

• RHEL or CentOS 7 (x86_64)

• 2 CPU cores

• 4 GB RAM

• Sufficient network bandwidth for handling data from the on-premises orchestrators that use the Secure Connector.

• Outgoing connectivity to the Secure Workload cluster on port 443 (direct or through HTTP(S) proxy).

• Outgoing connectivity to internal Orchestrator API servers (direct).

• To check if the Secure Connector client is installed, query the RPM database for the tet- secureconnector-client-site package by running the following command: rpm -q tet-secureconnector-client-site

• To check the state of the installed client, you can check the status of the tetration-secure- connector systemd service by running the following command: systemctl status tetration-secure-connector

The alert is generated when Secure Connector stops functioning or if there is no heartbeat in the past one minute.

Step 1: To enable alert, click Manage > Workloads > Secure Connector.

Step 2: Click the Alerts tab.

Step 3: Check the Enable Alert checkbox.

Step 4: Choose a Severity value from the drop-down.

Step 5: Click Update Config.

Note	Ensure that the Connectors alerts is enabled in the Manage > Alerts - Configuration page.

Navigate to Investigate > Alerts and click on an alert to view more details.

Alert text: Secure Connector: <reason for connection failure>

The Secure Connector client does not support automatic updates. To deploy a new version:

1. Run the following command to uninstall the current version: rpm -e tet-secureconnector-client-site

2. Deploy the new version. For detailed instructions, see Deploy the Secure Connector Client.

The Secure Connector Client can be uninstalled using the following command: rpm -e tet-secureconnector-client-site

• Security tokens (access key and secret key) used should have the right kind of IAM privileges to allow fetching of orchestrator information.

• Configure an AWS orchestrator filled with the configuration fields above.

Secure Workload adds the following labels to all the AWS instances.

The following labels are instance specific.

• Confusion between AWS Region and Availability Zone.

  Both these values are interrelated and should not be confused. For example us-west-1 might be the region and availability zone can be either of us-west-1a or us-west-1b etc. While configuring orchestrator, Region should be used. Refer to https://docs.aws.amazon.com/general/latest/gr/rande.html for all regions.

• Connectivity/Credentials issue after updating the orchestrator config.

  Customers must re-submit the AWS Secret Key every time the config gets updated.

• For supported Kubernetes and OpenShift versions, see https://www.cisco.com/go/secure-workload/requirements/integrations

• Secure Connector tunnel, if needed for connectivity.

The following configuration fields pertain to Kubernetes Orchestrator configuration in the Orchestrator Object.

The golden rules object attributes are described below. These golden rules allow a concise specification of rules necessary for the Kubernetes cluster to stay functional once enforcement is enabled on the Kubernetes cluster nodes.

The kubelet port is necessary to create policies to allow traffic from the Kubernetes management daemons to kubelets such as for live logs, execs of pods in interactive mode etc. Vital connectivity between the various kubernetes services and daemons is specified as a series of services - each entry in the services array has the following structure

• Description: A string that describes the service

• Addresses: A list of service endpoint addresses of the format <IP>:<port>/<protocol>.

• Consumed By: A list of consumers of the endpoints (allowed values are Pods or Nodes)

Note	If kubernetes is chosen as the type, Golden Rules configuration will be allowed.

• Configure Secure Connector tunnel, if needed, for connectivity from the Secure Workload cluster to a Kubernetes API server (or servers).

• Configure a Kubernetes orchestrator filled with the configuration fields above.

• Configure the Golden Rules for the Kubernetes orchestrator.

The Kubernetes client attempts to GET/LIST/WATCH the following resources. It is highly recommended NOT to configure the admin key/cert or an admin service account.

The provided Kubernetes authentication credentials should have a minimum set of privileges to the following resources:

Essentially, you can create a special service account on your Kubernetes server with these minimal privileges. An example sequence of kubectl commands is below that will facilitate the creation of this serviceaccount. Note the use of the clusterrole (not role) and clusterrolebindings (not rolebindings) - these are cluster-wide roles and not per namespace. Using a role/rolebinding will not work as Secure Workload attempts to retrieve data from all namespaces.

$ kubectl create serviceaccount csw.read.only

Create the clusterrole.

A sample clusterrole.yaml with minimal privileges is provided below

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: csw.read.only
    rules:
      - apiGroups:
        - ""
        resources:
          - nodes
          - services
          - endpoints
          - namespaces
          - pods
          - replicationcontrollers
          - ingresses
        verbs:
          - get
          - list
          - watch
      - apiGroups:
        - extensions
        - networking.k8s.io
        resources:
          - ingresses
        verbs:
          - get
          - list
          - watch
      - apiGroups:
        - apps
        resources:
          - replicasets
          - deployments
          - statefulsets
          - daemonsets
        verbs:
          - get
          - list
          - watch
      - apiGroups:
        - batch
        resources:
          - jobs
          - cronjobs
        verbs:
          - get
          - list
          - watch

    $ kubectl create -f clusterrole.yaml

Note	API groups for these different resources are susceptible to change across Kubernetes versions. The sample above should work for Kubernetes versions 1.20-1.24 and might require some tweaks for other versions.

Create the cluster role binding

$ kubectl create clusterrolebinding csw.read.only --clusterrole=csw.read.
˓→only --serviceaccount=default:csw.read.only

To retrieve the authtoken secret from the serviceaccount (used in the Auth Token field in the GUI) and decode from base64, you can retrieve the name of the secret by listing the serviceaccount with yaml output.

  $ kubectl get serviceaccount -o yaml csw.read.only
  apiVersion: v1
  kind: ServiceAccount
  metadata:
    creationTimestamp: 2020-xx-xxT19:59:57Z
    name: csw.read.only
    namespace: default
    resourceVersion: "991"
    selfLink: /api/v1/namespaces/default/serviceaccounts/e2e.minimal
    uid: ce23da52-a11d-11ea-a990-525400d58002
  secrets:
  - name: csw.read.only-token-vmvmz

Listing the secret in yaml output mode will yield the token but in Base64 format (which is standard Kubernetes procedure for secret data). Secure Workload does not accept the token in this format, you must decode it from Base64.

  $ kubectl get secret -o yaml csw.read.only-token-vmvmz
  apiVersion: v1
  data:
    ca.crt: ...
    namespace: ZGVmYXVsdA==
    token: ZXlKaGJHY2lPaUpTVX....HRfZ2JwMVZR
  kind: Secret
  metadata:
    annotations:
      kubernetes.io/service-account.name: csw.read.only
      kubernetes.io/service-account.uid: ce23da52-a11d-11ea-a990-525400d58002
    creationTimestamp: 2020-05-28T19:59:57Z
    name: csw.read.only-token-vmvmz
    namespace: default
    resourceVersion: "990"
    selfLink: /api/v1/namespaces/default/secrets/csw.read.only-token-vmvmz
    uid: ce24f40c-a11d-11ea-a990-525400d58002
  type: kubernetes.io/service-account-token

  $ kubectl get secret csw.read.only-token-vmvmz --template "{{ .data.token }}" | base64 -d

This authtoken can be used for configuring a Kubernetes orchestrator in the Secure Workload UI instead of username/password or key/cert.

See EKS specific RBAC considerations.

See Labels Related to Kubernetes Clusters.

• Client key or certificate Credentials parsing or mismatch

  These must be supplied in PEM format and be the correct entry from the kubectl.conf file. We have encountered customers pasting CA certs into client cert fields, as well as keys and certs not matching each other.

• Gcloud credentials instead of GKE credentials

  Customers using GKE under the gcloud CLI mistakenly provide the gcloud credentials when the GKE cluster credentials are needed.

• Kubernetes cluster version unsupported

  Using an incompatible version of Kubernetes may result in failures. Verify that the Kubernetes version is in the supported versions list.

• Credentials have insufficient privileges

  verify that the authtoken or user or client key or cert used has all the privileges listed in the table above.

• Kubernetes inventory keeps flipping around

  The hosts_list field specifies a pool of API servers for the same Kubernetes cluster - you cannot use this to configure multiple Kubernetes clusters. Secure Workload will probe for aliveness and randomly select one of these endpoints to connect to and retrieve the Kubernetes inventory information. No load balancing is performed here, nor is there a guarantee of evenly distributing load across these endpoints. If these are different clusters, the Kubernetes inventory will keep flipping between them, depending on which cluster’s API server we connect to.

• Multiple authorization methods

  Multiple authorization methods may be filled in during configuration (username or password, authtoken, client key or certificate) and will be used in the client connection established with the API server. The standard Kubernetes rules for valid simultaneous authorization methods apply here.

• SSL Certificate validation fails

  If the Kubernetes API endpoint is behind a NAT or load balancer, then the DN in the SSL certificate generated on the kube control plane nodes may mismatch with the IP address configured in Secure Workload. This will cause an SSL validation failure even if the CA certificate is provided and is valid. The Insecure knob bypasses strict server SSL certificate validation and will help workaround this issue but can lead to MITM issues. The correct fix for this is to change the CA certificate to provide SAN (Subject Alternative Name) entries for all DNS or IP entries that can be used to connect to the Kubernetes cluster.

• Secure Connector Tunnel, if needed for connectivity.

• vCenter version supported is 6.5+

Beside the common configuration fields as described in Create External Orchestrator the following fields can be configured:

• Hosts List is an array of hostname/ip and port pairs pointing to the vCenter server from which bare metal/VM attributes will be fetched.

• First, the user must verify that the vCenter server is reachable on that IP/Port from the Secure Workload cluster.

• For TaaS or in cases where the vCenter server is not directly reachable, the user must configure a secure connector tunnel to provide connectivity.

Secure Workload adds the following labels to all the VM’s learnt from vCenter server.

The following labels are instance specific.

• When an external orchestrator configuration is added for vCenter, Secure Workload software will connect to the vCenter server specified in the hosts list. After the connection to the server is successful, Secure Workload software will import hostnames, IP addresses and Category/Labels for all the bare metals and Virtual Machines present in the vCenter server. In order to import hostnames and IP addresses of the bare metals and VM’s, VM tools must be installed on all the bare metals and VM’s. If VM tools is not installed for a given bare metal/Virtual Machine, Secure Workload software will not display Category/Labels for that particular bare metal/VM.

• Secure Workload software doesn’t import Custom attributes of the bare metal/VM.

• It is recommended to set Delta interval timer to more than 10 min so as to reduce the load on the vCenter server. Any change in the inventory/labels on the vCenter server will have a propagation delay of at least 10 min, once the above mentioned timer is modified.

• Connectivity Issues

  In case, Secure Workload appliance is not able to connect/reach the vCenter server, Connection Status tab of the External orchestrator will display the failure status along with the appropriate error if any.

• Secure Workload software health check.

  Check the MAINTENANCE/Service Status page to see if any service is down. Check if OrchestratorInventoryManager is up and running.

• Secure Connector Tunnel, if needed for connectivity

• Supported DNS Servers: BIND9, servers supporting AXFR (RFC 5936), Microsoft Windows Server 2016

• DNS zones is an array of strings, each of which represents a DNS zone to be transferred from the DNS server. All dns zones must have a trailing period (“.”) character.

• Hosts List is an array of hostname/ip and port pairs pointing to the DNS server(s) from which to fetch the DNS records. Multiple DNS servers may be configured here for HA purposes only. High Availability behavior across multiple DNS servers specified in the hosts_list is “first healthy server” and will favor the earlier entries in the hosts_list. Zones cannot be split across the DNS servers.

• First, the user must verify that the DNS server is reachable on that IP/Port from the Secure Workload cluster.

• For TaaS or in cases where the DNS server is not directly reachable, the user must configure a secure connector tunnel to provide connectivity.

• Configure the correct DNS Zone Transfers ACLs/configuration on the DNS server. Refer to the documentation for the particular DNS server software for more information.

orchestrator_system/dns_name -> a multi-value field whose values are all the CNAME and A/AAAA hostnames pointing to that IP.

• The DNS orchestrator feed is a metadata feed - IP addresses learnt from a DNS zone transfer will not create inventory items in Secure Workload, rather, labels for an existing IP address will be updated with the new DNS metadata. DNS data for unknown IPs is silently discarded. In order to annotate DNS metadata to IPs not learnt from any sensor or via any other orchestrator integrations, IPs must be uploaded via the CMDB bulk upload mechanism to create inventory entries for them. Subnets learnt from CMDB uploads do not create inventory entries.

• Only CNAME and A/AAAA records from the DNS server are processed. CNAME records will be processed to their ultimate IPv4/IPv6 records via the A/AAAA records they point to. Only a single level of deferencing is supported (i.e. chains of CNAME -> CNAME -> A/AAAA or longer are not deferenced) as long as the CNAME points to an A/AAAA record from that same orchestrator. CNAME deferencing across different DNS orchestrators is not supported.

• Connectivity Issues

  Secure Workload will attempt to connect to the provided ip/hostname and port number using a TCP connection originating from one of the Secure Workload appliance servers or from the cloud in the case of TaaS or from the VM hosting the Secure Workload Secure Connector VPN tunnel service. In order to correctly establish this connection, firewalls must be configured to permit this traffic.

• DNS AXFR Privilege Issues

  In addition, most DNS servers (BIND9 or Windows DNS or Infoblox) require additional configuration when client IPs attempt DNS zone transfers (AXFR requests as per the DNS protocol opcodes) as these are more resource intensive and privileged as compared to simple DNS requests to resolve individual DNS records. These errors typically show up as AXFR refused with reason code 5 (REFUSED).

  Thus, any manual testing to establish that the DNS server is configured correctly must not depend on succesful hostname lookups but rather they must test AXFR requests specifically (using a tool such as dig).

  Any failure to perform an AXFR zone transfer from the DNS server will be reported in the “authentication_failure_error” field by Secure Workload appliance.

  Also, note that Secure Workload will attempt zone transfers from all configured DNS zones and all must succeed in order for the DNS data to be injected into the Secure Workload label database.

• Inventory Hostname fields are not populated by DNS Field ‘hostname’ is always learnt from the Secure Workload sensor. If the inventory was uploaded via CMDB upload and not from the sensor, it may be missing the hostname. All data from the DNS orchestrator workflow only shows up under the “orchestrator_system/dns_name” label and will never populate the hostname field.

Default Full Snapshot Interval is 24 hours

Default Delta Snapshot Interval is 60 minutes

These are also the minimum allowed values for these timers.

DNS Records may rarely change. So, for optimal fetching behaviour, at every delta snapshot interval, Secure Workload will check if the serial numbers of any of the DNS zones has changed from the previous interval. If no zones have changed, no action is needed.

If any zones have changed, we will perform a zone transfer from all configured DNS zones (not just the single zone that has changed).

Every full snapshot interval, Secure Workload will perform zone transfer downloads from all zones and inject into the label database regardless of whether the zone serial numbers have changed.

• Infoblox REST API endpoint supporting WAPI version 2.6, 2.6.1, 2.7, 2.7.1 (recommended)

Beside the common configuration fields as described in Create External Orchestrator the following fields can be configured:

Note	For Infoblox external orchestrator, IPv4 and IPv6 (dual stack mode) addresses are supported. However, do note that dual stack support is a BETA feature.

• First, the user must verify that the Infoblox REST API endpoint is reachable from the Secure Workload cluster.

• For TaaS or in cases, where the Infoblox server is not directly reachable, the user must configure a Secure Connector tunnel to provide connectivity.

• Create an external orchestrator with type Infoblox. Depending on the volume of Infoblox data, ie. the number of subnets, hosts and A/AAAA records it can take up to one hour for the first full snapshot is available in Secure Workload.

• While creating infoblox config, the user has an option to deselect any of the record types(subnet, host, A/AAAA records).

Secure Workload adds the following system labels to all objects retrieved from Infoblox.

All Infoblox extensible attributes will be imported as Secure Workload labels with the prefix orchestrator_. For instance, a host with an extensible attribute called Department can be addressed in Secure Workload inventory search as orchestrator_Department.

• The maximal number of subnets that can be imported from Infoblox is 50000.

• The maximal number of hosts and A/AAAA records that can be imported from Infoblox is 400000 in total.

• Connectivity issue Secure Workload will attempt to connect to the provided IP/hostname and port number using an HTTPS connection originating from one of the Secure Workload appliance servers or from the cloud in the case of TaaS or from the VM hosting the Secure Workload Secure Connector tunnel service. In order to correctly establish this connection, firewalls must be configured to permit this traffic. Also, make sure the given credentials are correct and have privileges to send REST API requests to the Infoblox appliance.

• Not all expected objects are imported Secure Workload imports only subnets, hosts and A/AAAA records with attached extensible attributes. Note there is a limit number objects that can be imported from Infoblox, see Caveats.

• Could not find subnets in inventory It is not possible to use inventory search to find Infoblox subnets as Secure Workload inventory by design includes only IP addresses, ie. hosts and A/AAAA records.

• Could not find a host or A/AAAA record Secure Workload imports all extensible attributes as retrieved from Infoblox. Remember to add the prefix orchestrator_ to the extensible attribute name in eg. inventory search. Note subnets extensible attributes, if not marked as inherited in Infoblox, are not part of hosts and hence not searchable in Secure Workload.

• Secure Connector Tunnel, if needed for connectivity

• F5 BIG-IP REST API endpoint version 12.1.1

Beside the common configuration fields as described in Create External Orchestrator the following fields can be configured:

• First, the user must verify that the F5 BIG-IP REST API endpoint is reachable from Secure Workload.

• For TaaS or in cases, where the F5 BIG-IP appliance is not directly reachable, the user must configure a Secure Connector tunnel to provide connectivity.

• Create an external orchestrator with type F5 BIG-IP.

• Depending on the delta interval value it might take up to 60 seconds (default delta interval) for the first full snapshot of F5 BIG-IP virtual servers to complete. Thereafter the generated labels can be used to create Secure Workload scopes and enforcement policies.

Secure Workload adds the following system labels for an external orchestrator for F5 BIG-IP:

For each virtual server the external orchestrator will generate the following labels:

This feature enables Secure Workload to translate logical policies with provider groups that match labelled F5 BIG-IP virtual servers into F5 BIG-IP security policy rules and deploys them to the load balancer appliance using its REST API. As mentioned above any assignment of existing security policy to the respective F5 BIG-IP virtual server will be replaced by a new assignment pointing to Secure Workload generated security policy. Existing security policies will not be changed or removed from the F5 BIG-IP policy list.

By default, enforcement is not enabled in the external orchestrator configuration:

This option can be modified any time as needed.

Enabling enforcement does not deploy policies to the load balancer appliance unless and until you enable enforcement in a workspace that includes at least one policy that applies to the load balancer, or due to any updates of inventories.

However, disabling enforcement for the orchestrator will cause all deployed security policy rules being removed from the F5 BIG-IP load balancer immediately.

Note

The orchestrator for F5 BIG-IP also detects any deviation of security policy rules and replaces it with Secure Workload policies, ie. any policy changes towards the virtual servers should be done with Secure Workload only. When policy enforcement is stopped or the external orchestrator is deleted, the security policy for virtual servers will become empty as all Secure Workload policies will be removed from F5 BIG-IP load balancer.

The OpenAPI Policy enforcement status for external orchestrator can be used to retrieve the status of Secure Workload policy enforcement to the load balancer appliance associated with the external orchestrator. This helps to verify if the deployment of security policy rules to the F5 BIG-IP appliance has succeeded or failed.

• During deployment phase of F5 BIG-IP HA mode, enable the configuration sync option. This ensures the external orchestrator can fetch the latest list of virtual servers from the currently connected host.

• In case of F5 BIG-IP HA deployment mode, if Auto-Map is configured instead of SNAT pool for Address translation, ensure that the Primary BIG-IP is configured with the floating Self IP address.

• Only VIP specified as a single address is supported, ie. VIP given as a subnet is not supported.

• Connectivity issue Secure Workload will attempt to connect to the provided IP/hostname and port number using an HTTPS connection originating from one of the Secure Workload appliance servers or from the cloud in the case of TaaS or from the VM hosting the Secure Workload Secure Connector tunnel service. In order to correctly establish this connection, firewalls must be configured to permit this traffic. Also, make sure the given credentials are correct and have privileges with read and write access to send REST API requests to the F5 BIG-IP appliance.

• Security rules not found In case no security rules for a defined virtual server are found, after policy enforcement was performed, make sure the corresponding virtual server is enabled, ie. its availability/status must be available/enabled.

• Secure Connector Tunnel, if needed for connectivity

• Netscaler REST API endpoint version 12.0.57.19

Beside the common configuration fields as described in Create External Orchestrator the following fields can be configured:

• First, the user must verify that the Netscaler REST API endpoint is reachable from the Secure Workload cluster.

• For TaaS or in cases, where the Netscaler appliance is not directly reachable, the user must configure a Secure Connector tunnel to provide connectivity.

• Create an external orchestrator with type Citrix Netscaler.

• Depending on the delta interval value it might take up to 60 seconds (default delta interval) for the first full snapshot of Netscaler virtual servers to complete. Thereafter the generated labels can be used to create Secure Workload scopes and enforcement policies.

• Enforce policies from Secure Workload to deploy Netscaler ACL rules.

Secure Workload adds the following system labels for an external orchestrator for Citrix Netscaler:

For each load balancing virtual server the external orchestrator will generate the following labels:

This feature enables Secure Workload to translate logical policies with provider groups that match labelled Citrix Netscaler virtual servers into Citrix Netscaler ACL rules and deploys them to the load balancer appliance using its REST API. As mentioned above all existing ACL rules will be replaced by Secure Workload generated policy rules.

By default, the field Enable Enforcement is not checked, ie. disabled, in the dialog Create Orchestrator as shown in the picture below:

Just click on the designated check box to enable enforcement for the orchestrator. This option can be modified any time as needed.

Enable enforcement for the orchestrator, regardless whether it is done by creating or editing the orchestrators configuration, will not deploy the current logical policies to the load balancer appliance immediately. This task is performed as part of the workspace policy enforcement to be triggered by the user as shown in the following picture or due to any updates of inventories. However, disable enforcement for the orchestrator will cause all deployed ACL rules being removed from the Citrix Netscaler load balancer immediately.

Note

The orchestrator for Citrix Netscaler also detects any deviation of ACL rules and replaces it with Secure Workload policies, ie. any policy changes towards the load balancing virtual servers should be done with Secure Workload only. When policy enforcement is stopped or the external orchestrator is deleted, the ACLs will become empty as all Secure Workload policies will be removed from Citrix Netscaler load balancer.

The OpenAPI Policy enforcement status for external orchestrator can be used to retrieve the status of Secure Workload policy enforcement to the load balancer appliance associated with the external orchestrator. This helps to verify if the deployment of ACL rules to the Citrix Netscaler appliance has succeeded or failed.

• If enforcement is enabled, the Secure Workload policies will always be deployed to the global list of ACLs, ie. partition default.

• Only VIP specified as a single address is supported, ie. VIP given as an address pattern is not supported.

• Visibility for the detected services (Citrix Netscaler virtual servers) is not supported.

• Connectivity issue Secure Workload will attempt to connect to the provided IP/hostname and port number using an HTTPS connection originating from one of the Secure Workload appliance servers or from the cloud in the case of TaaS or from the VM hosting the Secure Workload Secure Connector tunnel service. In order to correctly establish this connection, firewalls must be configured to permit this traffic. Also, make sure the given credentials are correct and have privileges with read and write access to send REST API requests to the Citrix Netscaler appliance.

• ACL rules not found In case no ACL rules are found, after policy enforcement was performed, make sure the corresponding virtual server is enabled, ie. its status must be up.

• Secure Connector Tunnel, if needed for connectivity

• Supported TAXII Servers: 1.0

• Supported TAXII feeds with STIX version: 1.x

Beside the common configuration fields as described in Create External Orchestrator the following fields can be configured:

• First, the user must verify that the TAXII server is reachable on that IP/Port from the Secure Workload cluster.

• Configure the correct TAXII server with the poll path and TAXII feed name.

• The TAXII integration is supported only on on-premise Secure Workload.

• Only IPs and hashes indicators from TAXII feeds are ingested.

• Maximum number of ingested IPs is 100K (most recently updated) per TAXII feed.

• Maximum number of ingested hashes is 500K (most recently updated) for all TAXII feeds.

• Only TAXII feeds with STIX version 1.x are supported.

• Connectivity Issues

  The Secure Workload will attempt to connect to the provided poll URL path from one of the Secure Workload appliance servers or from the VM hosting the Secure Workload Secure Connector VPN tunnel service. In order to correctly establish this connection, firewalls must be configured to permit this traffic.

Default Full Snapshot Interval is 24 hours

Every full snapshot interval, Secure Workload will perform pulling TAXII feeds of IPs and hashes up to the above limits into the label database.