System requirements of an Edge site

To use Edge, you must ensure that the following system requirements are met.

Tip 

You can install your Edge site on the installer bundled k3s or on a managed Kubernetes cluster.

Select your Kubernetes cluster:

Is it a dedicated or shared Kubernetes cluster?
What is your Edge site installation method?
 
       
 
Note 
  • A dedicated Kubernetes cluster only runs the Edge site. There are no other applications running in the cluster.
  • A shared Kubernetes cluster can run an Edge site and any other application. The collibra-edge namespace should contain only Edge resources.
    

Important You should only use the Helm Chart installation method if you are familiar with helm and Kubernetes. The following information is only an example, and as such, Collibra Support is limited to this specific setup and cannot assist with custom helm and Kubernetes configurations.

Software requirements

Tip If you are an early adopter or you use Edge for beta testing purposes, we highly recommend that you disable SELinux.

Hardware requirements

Note When installing on k3s, the Virtual Machine (VM) must be dedicated to a single Edge site installer.

You need the following minimum hardware requirements:

  • 64 GB memory.
  • 16-core CPU with x86_64 architecture.
  • At least 225 GB of free storage for Edge application storage requirements:
    • You have at least 50 GB of free storage on the partition that contains /var/lib/rancher/k3s. The partition mountpoint should not have the noexec option.
      mkdir -p /var/lib/rancher/k3s
mkfs.xfs /dev/<block-device-name>
mount /dev/<block-device-name> /var/lib/rancher/k3s
echo '/dev/<block-device-name> /var/lib/rancher/k3s xfs defaults 0 0' >> /etc/fstab
      Note This is the default install path. If it is not created as a separate mount point after following the steps above, the install will use 50 GB of disk space from either /var, or if not present, the root level of the drive.

      Warning Any data in this location is fully managed by the Edge site. Do not save any other data in this location as the data can be removed by Edge without notification.

    • You have at least an additional 5 GB of space in /var/log for Edge components. Edge uses hardcoded /var/log to write logs:
      • Up to 1.1 GB of space for writing K3S audit logs.
      • Maximum of 60 MB per container for pod logs. The number of containers depends on the workload.
    • You have at least an additional 200 GB of space on the partition that holds /var/lib/kubelet. uses hardcoded /var/lib/kubelet/pods//volumes/kubernetes.io~empty-dir/ to write ephemeral data related to kubernetes. We recommend dedicating this storage on the /var partition if it exits. If it does not exist, you can dedicate this storage on the /(root) partition.
      Note If you have technical lineage capabilities, each concurrent execution of these capabilities requires 10GB of space on /var/lib/kubelet. The number of technical lineage capabilities you can run concurrently depends on the available space on /var/lib/kubelet. If need to run more technical lineage capabilities concurrently than your have space for, you can use the auto-scaling mechanism within the managed k8s platforms.
  •  At least 500 GB of dedicated storage for Edge data storage requirements:
    • You have mounted at least 500 GB of dedicated storage for the Edge site data on a freely chosen mountpoint, for example, /var/edge/storage.

      mkdir -p /var/edge/storage
mkfs.xfs /dev/<block-device-name>
mount /dev/<block-device-name> /var/edge/storage
echo '/dev/<block-device-name> /var/edge/storage xfs defaults 0 0' >> /etc/fstab

      Note  Change <block-device-name> to the name of the device that contains the storage.

      Warning This dedicated storage must not be shared with other services because Edge can delete and overwrite files on this location without notice. Therefore, do not use /home/<username> or /var.

  • If you run the Linux server on AWS, Azure, or GCP, disable the services nm-cloud-setup.service and nm-cloud-setup.timer. 

    systemctl disable nm-cloud-setup.service nm-cloud-setup.timer 
reboot

Warning When new capabilities are added in the future, the hardware requirements may change.

Network requirements

  • Commercial
  • FedRAMP

Commercial

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.datadoghq.com: This URL is used to collect some of the logs from Edge for issue diagnosis. We do not send JDBC driver logs from Edge to Datadog.
    • https://*.repository.collibra.io: This URL serves as the primary source for downloading the latest Edge docker images from Collibra's docker registry and helm-chart repository.
      Note If the allowlist does not accept wildcards:
      • https://repository.collibra.io
      • https://edge-docker-delivery.repository.collibra.io
      • https://mirror-docker.repository.collibra.io
    • https://otlp-http.observability.collibra.dev/: This URL is used to ingest metrics and traces for monitoring the health and usage of Edge sites.
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.
Note 
  • Ensure that the network connectivity between the internal cluster and the service CIDRs use by k3s (which are by default 10.42.0.0/16 and 10.43.0.0/16) is not blocked.
  • In case firewalld is enabled, run the following commands to add the cni0 and loopback interfaces to a trusted zone, so that Kubernetes can use it between its services: 
    firewall-cmd --zone=trusted --change-interface=cni0 --permanent
firewall-cmd --zone=trusted --change-interface=lo --permanent
firewall-cmd --reload

FedRAMP

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.ddog-gov.com
    • https://*.artifactory-gov2prod.collibra.com/
      Note If the allowlist does not accept wildcards:
      • https://artifactory-gov2prod.collibra.com
      • https://edge-docker-delivery.artifactory-gov2prod.collibra.com
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.
Note 
  • Ensure that the network connectivity between the internal cluster and the service CIDRs use by k3s (which are by default 10.42.0.0/16 and 10.43.0.0/16) is not blocked.
  • In case firewalld is enabled, run the following commands to add the cni0 and loopback interfaces to a trusted zone, so that Kubernetes can use it between its services: 
    firewall-cmd --zone=trusted --change-interface=cni0 --permanent
firewall-cmd --zone=trusted --change-interface=lo --permanent
firewall-cmd --reload

Whats next

EKS requirements

You can install the Edge software on managed Kubernetes clusters.

Important Managed Kubernetes clusters can only contain one Edge site installer per cluster.

  • AWS EKS 1.27, 1.28, and 1.29 are supported for new and existing Edge sites.
  • EKS cluster has IRSA enabled.
  • Set up security groups to ensure that worker nodes can communicate with each other on non-privileged ports.

Software requirements

  • A Linux server with bash is available. This is the server from which you install the Edge software on EKS.

    Tip This server will also contain the Edge tools.

  • Helm (v3).
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
    • A user/service account with a role scoped to the collibra-edge namespace.
    • The rules within the role must at minimum be set to "*".
      Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
      • apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Helm (v3).
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
    • A user/service account with a role scoped to the collibra-edge namespace.
    • The rules within the role must at minimum be set to "*".
      Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
      • apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Ensure your kubectl client is compatible with the relevant EKS version.

Hardware requirements

You need an operational EKS cluster with at least 1 worker node that is running a Linux-based operating system. The cluster must meet the following requirements:

  • The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 4 worker nodes each with 4 core CPU and 16 GB.
  • Each worker node needs at least 100 GB free disk space to store Docker images.
  • We recommend you have at least 2 worker nodes in the EKS cluster.

Note  For more information about Linux OS for EKS clusters, go to the Amazon documentation about Amazon EKS optimized AMIs. As Edge sites are only compatible with Linux OS, disregard the Windows AMI option in this resource.

Network requirements

  • Commercial
  • FedRAMP

Commercial

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.datadoghq.com: This URL is used to collect some of the logs from Edge for issue diagnosis. We do not send JDBC driver logs from Edge to Datadog.
    • https://*.repository.collibra.io: This URL serves as the primary source for downloading the latest Edge docker images from Collibra's docker registry and helm-chart repository.
      Note If the allowlist does not accept wildcards:
      • https://repository.collibra.io
      • https://edge-docker-delivery.repository.collibra.io
      • https://mirror-docker.repository.collibra.io
    • https://otlp-http.observability.collibra.dev/: This URL is used to ingest metrics and traces for monitoring the health and usage of Edge sites.
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.

FedRAMP

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.ddog-gov.com
    • https://*.artifactory-gov2prod.collibra.com/
      Note If the allowlist does not accept wildcards:
      • https://artifactory-gov2prod.collibra.com
      • https://edge-docker-delivery.artifactory-gov2prod.collibra.com
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.

GKE requirements

You can install the Edge software on managed Kubernetes clusters.

Important Managed Kubernetes clusters can only contain one Edge site installer per cluster.

  • GKE 1.27, 1.28, and 1.29 are supported for new Edge sites.
    Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.

Software requirements

  • A Linux server with bash is available. This is the server from which you install the Edge software on GKE.

    Tip This server will also contain the Edge tools.

  • Helm (v3).
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
    • A user/service account with a role scoped to the collibra-edge namespace.
    • The rules within the role must at minimum be set to "*".
      Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
      • apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Helm (v3).
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
    • A user/service account with a role scoped to the collibra-edge namespace.
    • The rules within the role must at minimum be set to "*".
      Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
      • apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Ensure your Kubectl client is compatible with the relevant GKE version.

Hardware requirements

You need an operational GKE cluster with at least 1 worker node. The cluster must meet the following requirements:

  • The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 2 worker nodes each with 8 core CPU and 32 GB or 4 work nodes each with 4 core CPU and 16 GB.
  • Each worker node needs at least 100 GB free disk space to store Docker images.
  • We recommend you have at least 2 worker nodes in the GKE cluster.

Note At this time, Edge site installations on GKE clusters are only compatible with nodes running Linux-based operating systems. For more information about the currently supported Linux OS for GKE clusters, go to the Google documentation about Node images.

Network requirements

  • Commercial
  • FedRAMP

Commercial

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.datadoghq.com: This URL is used to collect some of the logs from Edge for issue diagnosis. We do not send JDBC driver logs from Edge to Datadog.
    • https://*.repository.collibra.io: This URL serves as the primary source for downloading the latest Edge docker images from Collibra's docker registry and helm-chart repository.
      Note If the allowlist does not accept wildcards:
      • https://repository.collibra.io
      • https://edge-docker-delivery.repository.collibra.io
      • https://mirror-docker.repository.collibra.io
    • https://otlp-http.observability.collibra.dev/: This URL is used to ingest metrics and traces for monitoring the health and usage of Edge sites.
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.

FedRAMP

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.ddog-gov.com
    • https://*.artifactory-gov2prod.collibra.com/
      Note If the allowlist does not accept wildcards:
      • https://artifactory-gov2prod.collibra.com
      • https://edge-docker-delivery.artifactory-gov2prod.collibra.com
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.

AWS Fargate using EKS requirements

You can install the Edge software on managed Kubernetes clusters.

Important Managed Kubernetes clusters can only contain one Edge site installer per cluster.

  • AWS Fargate using EKS on Kubernetes 1.27, 1.28, and 1.29 are supported for new Edge sites.
    Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.
  • EKS cluster has IRSA enabled
  • You must create an AWS Fargate profile for your cluster with the following namespace selectors:
    • kube-system
    • default
    • collibra-*
    • edge-kube-installer
  • EKS cluster has CoreDNS enabled and running on a Fargate Node(s).

Software requirements

  • A Linux server with bash is available. This is the server from which you install the Edge software on AWS Fargate using EKS.

    Tip This server will also contain the Edge tools.

  • Helm (v3).
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
    • A user/service account with a role scoped to the collibra-edge namespace.
    • The rules within the role must at minimum be set to "*".
      Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
      • apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Helm (v3).
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
    • A user/service account with a role scoped to the collibra-edge namespace.
    • The rules within the role must at minimum be set to "*".
      Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
      • apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Ensure your Kubectl client is compatible with the relevant EKS version.

Network requirements

Commercial

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.datadoghq.com: This URL is used to collect some of the logs from Edge for issue diagnosis. We do not send JDBC driver logs from Edge to Datadog.
    • https://*.repository.collibra.io: This URL serves as the primary source for downloading the latest Edge docker images from Collibra's docker registry and helm-chart repository.
      Note If the allowlist does not accept wildcards:
      • https://repository.collibra.io
      • https://edge-docker-delivery.repository.collibra.io
      • https://mirror-docker.repository.collibra.io
    • https://otlp-http.observability.collibra.dev/: This URL is used to ingest metrics and traces for monitoring the health and usage of Edge sites.
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.

OpenShift requirements

You can install the Edge software on managed Kubernetes clusters.

Important Managed Kubernetes clusters can only contain one Edge site installer per cluster.

  • OpenShift 4.14 and 4.15 are supported for new Edge sites.
    Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.

Software requirements

  • A Linux server with bash is available. This is the server from which you install the Edge software on OpenShift.

    Tip This server will also contain the Edge tools.

  • Helm (v3).
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
    • A user/service account with a role scoped to the collibra-edge namespace.
    • The rules within the role must at minimum be set to "*".
      Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
      • apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Helm (v3).
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
    • A user/service account with a role scoped to the collibra-edge namespace.
    • The rules within the role must at minimum be set to "*".
      Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
      • apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Ensure your Kubectl client is compatible with the relevant OpenShift version.

Hardware requirements

You need an operational OpenShift cluster with at least 1 worker node. The cluster must meet the following requirements:

  • The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 4 worker nodes each with 4 core CPU and 16 GB.
  • Each worker node needs at least 100 GB free disk space to store Docker images.
  • We recommend you have at least 2 worker nodes in the OpenShift cluster.

Note At this time, Edge site installations on OpenShift clusters are only compatible with nodes running Linux-based operating systems. For more information about the currently supported Linux OS for OpenShift clusters, go to the OpenShift documentation.

Network requirements

  • Commercial
  • FedRAMP

Commercial

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.datadoghq.com: This URL is used to collect some of the logs from Edge for issue diagnosis. We do not send JDBC driver logs from Edge to Datadog.
    • https://*.repository.collibra.io: This URL serves as the primary source for downloading the latest Edge docker images from Collibra's docker registry and helm-chart repository.
      Note If the allowlist does not accept wildcards:
      • https://repository.collibra.io
      • https://edge-docker-delivery.repository.collibra.io
      • https://mirror-docker.repository.collibra.io
    • https://otlp-http.observability.collibra.dev/: This URL is used to ingest metrics and traces for monitoring the health and usage of Edge sites.
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.

FedRAMP

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.ddog-gov.com
    • https://*.artifactory-gov2prod.collibra.com/
      Note If the allowlist does not accept wildcards:
      • https://artifactory-gov2prod.collibra.com
      • https://edge-docker-delivery.artifactory-gov2prod.collibra.com
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.

AKS requirements

You can install the Edge software on managed Kubernetes clusters.

Important Managed Kubernetes clusters can only contain one Edge site installer per cluster.

  • AKS 1.27, 1.28, and 1.29 are supported for new Edge sites.
    Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.

Software requirements

  • A Linux server with bash is available. This is the server from which you install the Edge software on AKS.

    Tip This server will also contain the Edge tools.

  • Helm (v3).
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
    • A user/service account with a role scoped to the collibra-edge namespace.
    • The rules within the role must at minimum be set to "*".
      Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
      • apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Helm (v3).
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
    • A user/service account with a role scoped to the collibra-edge namespace.
    • The rules within the role must at minimum be set to "*".
      Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
      • apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Helm (v3).
  • You must have yq and jq installed on your Linux machine.
  • You must have a kubeconfig file with plain cluster_admin kubectl access to the EKSAKSAWS Fargae using EKSOpenShiftGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
    Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
  • The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
  • Ensure your Kubectl client is compatible with the relevant AKS version.

Hardware requirements

You need an operational AKS cluster with at least 1 worker node. The cluster must meet the following requirements:

  • The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 2 worker nodes each with 8 core CPU and 32 GB or 4 work nodes each with 4 core CPU and 16 GB.
  • Each worker node needs at least 100 GB free disk space to store Docker images.
  • We recommend you have at least 2 worker nodes in the AKS cluster.

Note At this time, Edge site installations on AKS clusters are only compatible with nodes running Linux-based operating systems. For more information about the currently supported Linux OS for AKS clusters, go to the Azure documentation about Azure Kubernetes core concepts.

Network requirements

  • Commercial
  • FedRAMP

Commercial

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.datadoghq.com: This URL is used to collect some of the logs from Edge for issue diagnosis. We do not send JDBC driver logs from Edge to Datadog.
    • https://*.repository.collibra.io: This URL serves as the primary source for downloading the latest Edge docker images from Collibra's docker registry and helm-chart repository.
      Note If the allowlist does not accept wildcards:
      • https://repository.collibra.io
      • https://edge-docker-delivery.repository.collibra.io
      • https://mirror-docker.repository.collibra.io
    • https://otlp-http.observability.collibra.dev/: This URL is used to ingest metrics and traces for monitoring the health and usage of Edge sites.
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.

FedRAMP

  • An Edge site needs outbound connections to all of the following:
    • The URL of your Collibra Data Intelligence Platform environment.
    • https://http-intake.logs.ddog-gov.com
    • https://*.artifactory-gov2prod.collibra.com/
      Note If the allowlist does not accept wildcards:
      • https://artifactory-gov2prod.collibra.com
      • https://edge-docker-delivery.artifactory-gov2prod.collibra.com
  • Access to all data sources you need to connect to your Edge sites.
  • Your Edge site has to be able to connect to port 443.
  • Set the Linux system value for IP forwarding to 1: net.ipv4.ip_forward=1
    Note If IP forwarding is turned off (net.ipv4.ip_forward=0), your Edge site may become unhealthy. Follow the steps in this Support article to turn IP forwarding on.
  • If you intend to use a man-in-the-middle (MITM) proxy, you need to add the specific truststores customization to the ca.pem, because Edge does not use the host TLS trustsore. For more information, go to Configure a forward proxy.
  • The resolve configuration file of your Linux host has maximum three search domains and two name servers.

Whats next