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:
What is your Edge site installation method?

Which Edge CLI method do you want to use?

  
       

Important The default Edge CLI method is an easier solution for installing your Edge site via the Edge CLI. Edge creates the cluster level objects, such as namespaces, CRDs, and priority classes for you. This method can be used for both dedicated and shared clusters.

Important The restrictive Edge CLI method allows you or your company to create the cluster level objects, such as namespaces, CRDs, and priority classes, for your Edge site. This method may be required if your company has security requirements or process that do not allow Edge sites to create the cluster level objects for you. This method can be used for both dedicated and shared clusters.

Warning Collibra Support will not assist with custom Helm or Kubernetes configurations. The following steps are an example, and any assistance for configurations or issues outside of these steps is unsupported. We recommend using the Edge CLI method for managed Kubernetes installations.

A common example of custom Helm configurations is, but not limited to, using an unsupported private repository. At this time, we only support a JFrog repository.

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.
      Copy
      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. k3s uses hardcoded /var/lib/kubelet/pods/<containerId>/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.

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

    Copy 
    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:
    Copy
    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:
    Copy
    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, 1.29, and 1.30 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 for x86_64 architecture where 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.

  • 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.
  • 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, 1.29, and 1.30 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 for x86_64 architecture where 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.

  • 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.
  • 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, 1.29, and 1.30 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 for x86_64 architecture where 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.

  • 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.
  • 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, 4.15, and 4.16 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 for x86_64 architecture where 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.

  • 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.
  • 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, 1.29, and 1.30 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 for x86_64 architecture where 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.

  • 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.
  • 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.

For the network requirements specific to creating a technical lineage, go to Lineage harvester system requirements.

Whats next