(Revision 1.2, March 2023)
Product specifications and availability are subject to change without notice. Dalet is a registered trademark owned by Dalet. All other brands and trademarks are those of their respective owner.
Dalet Pyramid service has been designed with Cloud-native approach.
At the time of this writing, Dalet Pyramid can be offered :
- As a pure SaaS service, fully hosted and operated by Dalet. This option will remain over time and will always be the recommended approach, maximizing the Service Level Agreements (SLA) and level of service delivery quality Dalet can provide.
- As a customer-hosted service, while still operated by Dalet. Operating on a shared-responsibility basis, this approach is known to be less efficient than its pure SaaS service counterpart. When selected, the customer will have two distinct hosting options:
- On Cloud, on a supported dedicated Cloud provider account of his choice.
- On-Premises (Not yet available)
Regardless of these deployment topologies, Pyramid may require connection with Dalet Galaxy system(s), which may:
- be newly installed on Cloud environments
- already exists, generally deployed on customer's premises.
This document provides the Pyramid traditional operational requirements when the Dalet-hosted approach is considered and associated with a customer-hosted Galaxy. The exact requirements may however vary, depending on the nature of the infrastructure and customer’s private security policy and Dalet Operations team is able to accommodate to some specific variations.
Please note that any deviance from the usually offered and supported requirements is subject to either increase the cost of the delivered solution as subject to customization and/or lower down the global quality of the service, SLA and capacity to provide accurate and timely customer support.
Customer-dedicated deployments require a shared-responsibility operational approach with clearly defined and respected boundaries between customer and Dalet IT organizations. Dalet services can be contractually offered from 3 distinct ways:
- The default Supported way, where:
- Customer is in charge of providing (and ensuring reliability, durability and scaling) of the underlying infrastructure, including but not limited to networking, computing and storage resources.
- Dalet is in charge of supporting the deployed service itself, including its maintenance and upgrade processes. Dalet’s responsibility is limited to a per customer request, support delivery activity, offering software maintenance and software updates delivery.
- Customer oversees the day-to-day monitoring and right-behavior of the service and reach out to Dalet’s customer service in case of incapacity from the service to operate properly.
- The extended Managed Services way, where 24x7 monitoring, alarming, and troubleshooting of the Dalet's service is delegated by customer to Dalet’s Cloud Operations teams, to the extent that:
- The underlying infrastructure remains the customer’s responsibility and Dalet will not intervene to mitigate out-of-control issues.
- The proper remote administration capabilities must be provided by the customer to Dalet for the service to be properly operated.
- The Private SaaS way, where:
- Dalet provides a complete dedicated Cloud hosting service on behalf of the customer, ensuring a proper redundancy, high-availability and scalability of the solution.
- Provides offloads the customer from all operational troubles, providing the same 24x7 coverage than offered by the Managed Services subscription
- Provides an additional level of SLAs, platform's scrutiny and security awareness.
The matrix below summarizes the split of roles and responsibilities between Dalet and its Customer:
|Theme||Feature||Supported||Managed Services||Private SaaS|
|Computing, Storage, Network Resources||Customer-Provided||Customer-Provided||Dalet-Provided
|Software||Dalet Software Delivery||Dalet-Provided||Dalet-Provided||Dalet-Provided|
|Dalet Software Updates||Dalet-Provided||Dalet-Provided||Dalet-Provided|
|Security Updates||Dalet-Provided (Dalet SW Only)||Dalet-Provided (Dalet SW Only)||Dalet-Provided (OS + SW)|
|Service Backup||Backup Management||Customer-Provided||Monitored||Dalet-Provided|
|Monitoring & Troubleshooting||Security Engineers (SOC)||Customer-Provided||Dalet-Provided||Dalet-Provided|
|Monitoring Engineers (MOC)||Customer-Provided||Dalet-Provided||Dalet-Provided|
|24x7 Alerts Management||Customer-Provided||Dalet-Provided||Dalet-Provided|
For hybrid Pyramid/Galaxy deployments, the following responsibilities apply:
|Galaxy Hosting Infrastructure||Customer|
|Pyramid Hosting Infrastructure||Dalet|
Pyramid Typical Deployment Overview
At present time, Pyramid requires being deployed, hosted and managed by Dalet Cloud Operations team only, on an Dalet-owned AWS account (though dedicated to each customer platform).
Dalet Pyramid key Cloud infrastructure components are usually deployed the following way:
- 1 region with 3 Availability Zones (AZs) or assimilated, across a shared L2/L3 network.
- 1 frontal classic load balancer, accepting users traffic and request and routing them backend to Pyramid's backend.
- 1 multi-AZ Kubernetes cluster, running Pyramid Cloud-native applications spread evenly amongst AZs and workers.
- Legacy Windows instance(s) with Galaxy backend.
- MSSQL on RDS
- Postgres SQL on RDS
- Media files are stored in region based S3 buckets. No cross-region replication is configured. S3 is configured with AES-256 server-side encryption.
Pyramid's platform application logs and key technical metrics are sent over Dalet's global Control Tower for large-scale monitoring and possible troubleshooting.
For Pyramid to run properly, a few things are expected from customer side:
- an Identity Provider, supporting Active Directory (AD), OpenID or SAML protocols.
- optionally, an existing Galaxy remote site with its associated storage.
In most cases, it is unlikely that such services are configured to be publicly exposed over Internet, hence can't be connected to Pyramid's instance.
Multiple options can be considered for that purpose (see next section) but both aim at providing a secure communication tunnel between customer premises on Cloud instances. In most cases, Dalet offers to support customers with a virtualized network equipement (Iris Gateway), providing such connectivity means, and ensuring that Dalet provides and end-to-end solution.
The following diagram provides an example overview of such topology.
An alternative hybrid deployment exists, in the case customer requires to:
- optionally keep control of the networking stack and associated resources. The customer is then in charge of providing the networking remote access capability, allowing Pyramid to reach out on-premises resources. It is up to the customer to define the scope of access, for instance, should the service be exposed on public Internet or restricted to a private network, and exposing routing tables in a secure way to Cloud VPC of its own, where the termination to Dalet's AWS account can finally happen.
- optionally keep control of the media assets Cloud storage (S3) instead of leveraging Dalet's account resources.
The following diagram provides an example overview of such topology.
Customer hosting the deployment requires more complexity:
- The customer is then in charge of providing the networking remote access capability, allowing Pyramid to reach out on-premises resources. It is up to the customer to define the scope of access, for instance, should the service be exposed on public Internet or restricted to a private network, and exposing routing tables in a secure way to Cloud VPC of its own, where the termination to Dalet's AWS account can finally happen.
- In the case of an EKS cluster with a private endpoint only accessible through a bastion, Dalet requires a set of tool in order to deploy, operate and maintain the Kubernetes cluster (more details in Infra).
The following example assumes a fully customer-hosted private mode.
IMPORTANT: Hybrid SaaS and Customer Hosted approach implies more responsibility on customer and will automatically lower-down Pyramid’s expected level of resilience, availability and will be out of Dalet’s control and support.
Supported Hosting Provider
At the time of this writing, Dalet Pyramid can be deployed on the following infrastructure providers:
- Dalet Cloud, on AWS
NOTE: Support for on-premise customer-hosted deployments, including more Cloud providers will come in time.
On deployment, upgrades and possibly fixes, administrative rights are required to create the different resources, the needed IAM roles and permissions, and the OIDC provider for the kubernetes cluster service accounts
At all time, a minimum of Read-Only rights are needed to the AWS Console for Dalet Ops team
When customer hosted, the customer shall provide at least 3 /24 subnets which is due to EKS pod networking management. Another 3 public subnets for the AWS load balancer are required if Pyramid should be publicly accessible. The customer shall allow Dalet to tag the subnets with the following keys:
From service usage perspective
Several network-oriented considerations must be circled out to allow end-users to connect to the Dalet Pyramid service.
The customer shall provide a domain name for Dalet Pyramid to be hosted upon. The chosen domain can be either a public or private domain depending on the targeted usage (service exposed over Internet or restricted to private usage).
The domain name configuration can either be managed by the customer or by Dalet CS Ops team (recommended). The selected domain name is to be provided by the customer. If the customer prefers Dalet to provide a dedicated domain, Dalet offers free usage of the dalet.cloud generic domain. The customer’s Pyramid system will then be made available under pyramid.<customer-env>.dalet.cloud domain.
Dalet strongly recommends to setup a dedicated DNS sub-zone for Pyramid (one sub-zone per environment, e.g: production, staging, QA …). This process can ease the DNS creation automation.
IMPORTANT: The DNS configuration is usually managed by Dalet through automation process. Dalet currently supports AWS Route53 only. If the customer’s selected DNS provider is different, customer will either (1) manage the Pyramid DNS configuration by himself or (2) require an additional customization effort from Dalet teams at an additional charge.
Should the customer not being able to provide a DNS sub-zone for Dalet to manage it, the following DNS A entries will need to be added. More might be needed, depending on the customer requirements):
- dashboard.<domain_name> OR dashboard.pyramid.<domain_name>
If an external cube engine is used :
The underlying IP addresses mapping is to be disclosed after initial deployment. Multi-A entries need to be supported by the DNS provider to offer high-availability mechanisms.
Dalet requires a certificate with the following pattern <pyramid_hostname>.<customer_domain> (When managed by Dalet, this is fully automated by Dalet deployment scripts.) The certificate may require SAN depending on the deployed application.
The SSL certificate can be obtained in different ways:
- Customer requires Pyramid to use the customer-provided SSL certificate
- Dalet then suggests that the provided SSL certificate is at least RSA-2048 or EC-256 encrypted, with a SHA-256 digital signature and a 1y minimal validity. These encryption requirements are considered to be safe enough to nowadays standards while keeping a wide compatibility with modern client OSes and browsers.
- The customer is responsible for the proper management (including expiry) of the certificate provided. Dalet requires the customer to provide the renewed certificate within 30 days prior to expiry to ensure a continuity of service.
- The customer agrees to provide Dalet with both the public SSL certificate, the associated private key and the intermediate CA certificates to ensure a valid chained certificate.
- Note that Dalet strongly discourages the customer-provided SSL certificate approach, as it may lead to more complexity in SSL management and may induce possible side-effects and unavailability of the service.
- Customer agrees to use a Dalet-provided SSL certificate (recommended)
- Dalet will then be responsible for global end-to-end security provided by this SSL certificate.
- A Let’s Encrypt issued certificate will be used, with auto-renewal support.
Dalet Pyramid requires load balancer(s) to provide users access to the actual backend services.
The load balancers are responsible of:
- Exposing Pyramid backend services to users.
- Offering a highly available entry point to Dalet Pyramid.
- Offloading (or terminating) the incoming SSL-secured HTTPS traffic.
Load balancers are used “as-a-service”, through AWS Classic LB component,
Load balancers can be, depending on customer requirements, configured to be:
- Publicly available, exposing Pyramid services over public Internet (recommended)
- They consequently require to be exposed through one or many public IP addresses and secured (firewall) accordingly.
- Private-only, limiting Pyramid services exposure to private users.
- In such a scenario, the customer remains responsible to ensure access from its internal network to the Pyramid Cloud application.
The load balancers only expose the following ports:
- TCP/80 (HTTP)
- TCP/443 (HTTPS)
For on-premises service administration perspective
When Dalet is mandated to manage the hybrid connectivity between customer's premises equipment and Pyramid system on cloud, some extra requirements apply:
Dalet CS Ops team requires an SSH connectivity to the customer's on-premises network gateways for initial installation, upgrade, configuration or debugging of the environment. This SSH connectivity is mandatory for Dalet to perform the service operation. SSH access can however (more than recommended) be limited to private access through the usage of peering or VPN-like connections and doesn’t require servers to be exposed over Internet.
When per-server SSH access is not possible, Dalet CS Ops team may use a bastion or jump host as a possible SSH-relay alternative. This jump host is expected to be Linux/UNIX-based.
On-Premises egress (When using Dalet's Iris' virtualized network gateway equipment)
Deployed Iris servers need to have Internet egress access to:
- Dalet packages repository
- Linux distribution repository
- <to be completed>
IMPORTANT: The SSH connectivity is the only way for Dalet CS Ops and Support teams to provide efficient deployment, management, troubleshooting, and mitigation of possible incidents. If customer is not able to or doesn’t allow such requirement, the expected level of serviceability and quality of customer service will be greatly weakened and Dalet may not perform as per the SLA, falling to a degraded best-effort approach.
IMPORTANT: “Remote display” mechanisms through browser-based or dedicated applications and protocols like RDP, TeamViewer or similar are not supported options nor an SSH replacement. While such alternatives are somehow possible, the efficiency of support will fall in the same “best-effort” approach as previously mentioned.
Remote Network Gateway Administration / Support
Dalet requires a network connection between customer’s private infrastructure and Pyramid's one on Cloud to communication.
Dalet’s Customer Remote Administration process relies on the following:
- Dalet CS Ops team members authenticate through a corporate LDAP-based MFA-enforced portal to ensure of their identity and authorization / ability to manage customer platforms.
- Once authenticated, they establish a secure one-way VPN tunnel to Dalet’s Cloud Operations administration network and platform.
- Dalet’s Cloud Operations network is connected to customer’s infrastructure and Dalet Ops members can establish an SSH remote connection from there on.
From Dalet’s Cloud Operations network, multiple ways of connecting with customer’s infrastructure are considered and supported (sorted by prefered option):
AWS Infrastructure Connectivity: VPC Peering with Dalet CSOps VPC
- This allows the CSOps team to administer all AWS resources
- Pros: This is the fastest and reactive access and will greatly reduce response time on incident. It will also reduce time on the deployment
Site-to-Site IPSec VPN Tunnel
- This allows connecting Dalet’s Cloud Administration network with virtually any customer’s platform through public Internet over a secured VPN.
- Pros: fast and easy access to customer’s environments when it comes to troubleshooting, allows for the customer to control / restrict / limit the subnets to be accessed to.
Customer-provided Bastion Host
- Customer provides a Linux jumphost with SSH access that Dalet’s Ops team members can use as relay to SSH to network gateways.
- In order to deploy, operate and maintain, Dalet requires root privileges on a instance (It can be the bastion or a server accessible through it)
- Dalet can also provide a toolbox image for that purpose
- Pros: SSH connectivity is still manageable.
- Cons: Customer must provide bastion access to all Dalet CS Ops team members and manage individual contributors’ security. Incapacity from customer to do so will result in a degraded operational quality. Connections will be established from Dalet’s CS Ops team members instead of centralized trusted Cloud Administration network platform with may increase security concerns.
- Dalet will not support a Windows-based bastion host (unless WSL is available and configured) or a host with no outgoing Internet connection.
Customer-provided VPN access
- Customer provides a VPN access to access to network gateways.
- Pros: SSH connectivity is still manageable.
- Cons: Customer must provide nominative VPN access to all Dalet CS Ops team members and manage individual contributors’ security. Incapacity from customer to do so will result in a degraded operational quality. Connections will be established from Dalet’s CS Ops team members instead of centralized trusted Cloud Administration network platform with may increase security concerns. Customer must authorize multiple concurrent VPN connections as to allow Dalet Ops team members to perform simultaneous troubleshooting
- IMPORTANT: Customer-provided Bastion host and dedicated VPN access, while supported, are not recommended. These approaches usually imply heavy changes in terms of access rights, human resources management, and greatly impact Dalet’s responsiveness to incident and capacity to support. If these approaches are considered, Dalet may not perform as per the SLA, and support will fall back to a ‘best-effort’ approach. If this approach is chosen, Dalet CS Ops team requires a Unix-Based/Linux administration VM with root privileges with internet connectivity to achieve the deployment
Hybrid Network Connectivity
Dalet Pyramid requires connectivity to customer's services which are likely to only be hosted on-premises and not publicly available. Different ways can be considered to achieve that purpose:
- Public exposure of the required services to Pyramid Cloud platform. This relies on customer offering public access routing to his private network (direct connection or behind NAT gateways and firewalls).
- Integration of free-of-charge Dalet's Iris virtualized network gateway equipment, providing a secure VPN tunnel between customer on-premises private network and Pyramid Cloud private network (recommended approach).
- Use of a third-party customer-provided network gateway equipment, providing the same kind of secure VPN tunnel between customer on-premises private network and a customer-managed private cloud, peered with Dalet's Pyramid Cloud account.
If no specific VPN tunnel is foreseen, it is up to the customer's IT to ensure that the following services and port are accessible from Pyramid (Cloud) over a specific port and protocol. It is up to the customer to set this up in a secure and reliable way. It is up to the customer to decide on whether or not the aformentionned services should be fully exposed publicly and directly or behind NAT and/or firewall using IP whitelisting etc ...
For Pyramid Planning package, the mandatory following service exposure is required:
- SMTP (UDP/25, TCP/25)
- SMTPS (TCP/465)
- TCP/53, UDP/53
Active Directory Domain Services (AD DS):
- LDAP (UDP/389, TCP/389)
- LDAPS (TCP/636, UDP/636)
Galaxy Solr Indexer:
The Pyramid Production package, requires the additional service exposure on top of the default ones:
Adobe Media Encoder:
IMPORTANT: The list of services to be exposed is subject to change over Pyramid's lifecycle and proper service exposure falls under customer's responsibility. Dalet cannot be held responsible for any kind of security side-effects induced by such exposure nor able to support customer should Pyramid fail to be able to reach out the aformentionned services.
Dalet Iris Network Gateway (Full SaaS)
The most straightforward and recommended approach for hybrid networking provided by Dalet Iris Network Gateway.
Iris is a network gateway solution that aims to provide site-to-site connectivty, as to interconnect a Cloud provider to an on-premise infrastructure. Iris is a custom Linux OS to be installed on metal or virtualized servers on customer premises. It provides the following optional networking services:
- Core network services:
- Router (static, BGP, OSPF)
- Connectivity services:
- IPSec site-to-site VPN
- WireGuard client-server VPN
- Client-Server OpenVPN
The following diagram exposes how Iris offers edge network connectivity:
Iris being a router, it allows for bi-directional traffic between 2 locations over a restricted list of protocols.
Subnets must be known and shared by both Pyramid & Galaxy to setup IPSec connection (when enabled) and the routing. The Galaxy servers will need to have a route defined to reach the Pyramid endpoints. This can be done by the customer network team or on the Galaxy server themselves in the case Iris servers are located in the same subnet than Galaxy. We recommend using BGP protocol to exchange routes
Pyramid servers will need to have a route defined to reach the Galaxy server. This is implemented by Dalet as part of the Cloud deployment. DNS resolution can also be needed to ensure the Galaxy server can resolve the Pyramid DNS names if the DNS entries are not public.
Customer Third-Party Network Gateway (Hybrid SaaS)
Customer may choose to use its own network gateway to provide hybrid networking and decide not to go with Dalet Iris. When such an option has been selected, it becomes customer's responsibility to deploy, administrate and manage a third-party solution of its own, provided it features a routed tunnel between customer's premises and a Cloud account.
The Dalet recommended approach is for customer to provide network connectivity between his premises and an AWS account under his control. This ensures customer's IT teams to have full control offer the networking traffic flowing between the two peers. Connectivity between Dalet's Pyramid on AWS is then achieved through a matter of a simple AWS VPC peering.
NOTE: Dalet highly recommends the network gateway to be deployed in a highly-available and resilient manner, to ensure a possible network loss will not prevent Pyramid services from being down.
IMPORTANT: It is up to the customer to fully manage the hybrid connectivity solution, from end-to-end. This includes commercial contract with the chosen third-party solution vendor, setup, network routing and end-to-end security and resilience and 24x7 management. Dalet cannot be held responsible for any deficience on networking side as solely operating the Cloud VPC end.