Self-hosted Veza (AWS VPC)
Learn about deploying Veza Enterprise SaaS on your own cloud infrastructure
Overview
Veza Enterprise SaaS is available for cloud-premises deployment within a customer-managed AWS Virtual Private Cloud (VPC). This option enables a fully isolated installation where all access to Veza is controlled within a customer's own AWS account and cloud infrastructure. A customer-managed deployment is often necessary for regulatory compliance in industry verticals such as financial services and healthcare.
To install and upgrade the self-hosted deployment, Veza support staff will coordinate with the enterprise customer to:
Decide on the appropriate level of external communication for logging and issue detection: To support the deployment, Veza expects to use a self-provided SOC2-compliant external logging tool, and restrictions on outbound logging and alerting communications will dramatically impact supportability. Network and security teams should agree on a policy for exporting data outside of the VPC environment.
Configure an AWS bastion host jump box: A virtual machine will enable a secure gateway for external access to the customer-managed VPC. The Veza team can initialize the VM, or work with the customer to start and configure the VM, which serves as the point of entry for Veza SaaS installation and upgrades. The bastion host jump box must be accessible by the Veza team by VPN or VPC peering.
Deploy Veza Enterprise SaaS: After configuring the bastion host, Veza staff will begin the deployment process within the AWS VPC and verify functionality before handing off to the customer.
Perform periodic upgrades and maintenance: After the initial deployment, Veza staff will access the bastion host to conduct routine upgrades. This includes applying patches, bug fixes, and other necessary updates. Veza follows a weekly release cadence. However, customers have the flexibility to delay updates during critical periods, for example, while an access review campaign is ongoing.
This document provides an overview of downloading and installing a custom Veza release in a production, staging, or QA environment using a Linux bastion host and a GitOps-based workflow. For additional guidance on evaluating and implementing Veza in customer-managed AWS VPC environments, please reach out to our sales engineering and customer success teams.
Deployment architecture
All access to the cluster is performed over HTTPS
Maintenance is done via the bastion accessed by SSH
All outbound webhooks are HTTP or HTTPS
Email is sent via SMTP, with credentials provided by the customer or set up in SES
All logs and alerting data is sent via HTTPS
Images essential to run the service are pulled from AWS ECR by assuming a read-only role in the production Veza AWS account. Veza does not mirror images to the customer account at release.
Self-hosted Veza FAQ
Question: Which version of Linux is recommended? Are there specific EC2 tech specs? is a separate AMI required?
Answer: There is no specific required version of Linux or Amazon Machine Image (AMI). It is only used for running the Veza deployer. We recommend using the latest version of Amazon Linux, Red Hat Enterprise Linux, or Ubuntu.
The deployer is tested on:
Amazon Linux 2 2.0.20230314
Red Hat Enterprise Linux 8.6
Ubuntu 22.04 LTS
Question: Is a specific Docker version required?
Answer: We recommend using Docker version 19.03.8, or the latest version installed with Amazon Linux. Docker CE or an equivalent may be used.
Question: Where is the Veza ECR located?
Answer: The ECR repository is in our production AWS account. You will be provided with the account ID and authorized to pull deployer images.
Question: Does Veza use AWS role ARNs or bespoke Kubernetes authentication?
Answer: Role ARNs, created and managed by the deployer using terraform.
Question: Do we need to provision an EKS cluster to install Veza?
Answer: No, the deployer automatically provisions and manages all resources, including an EKS cluster within your AWS account.
Question: Are automatic updates optional?
Answer: Updates are only applied at deploy time, which you can manage. For security and supportability reasons, you must deploy a new version of the software every 8 weeks.
Prerequisites
To use the deployer, customers must provide an AWS account and an AWS IAM role with the necessary permissions to create the required resources, including
A virtual private cloud (AWS VPC) with public and private subnets.
AWS ENI with private IPs for EKS pods.
Three AWS EC2 instance autoscaling groups, one per availability zone (AZ).
AWS Encrypted EBS + Snapshots.
AWS S3 bucket (Server side encrypted).
AWS Elastic Load Balancer (ELB) + WAF.
AWS Elastic Kubernetes Service (EKS).
AWS CloudWatch logs.
AWS Key Management Service (KMS) and AWS Certificate Manager (ACM).
AWS IAM roles (used to set up IAM roles and policies for EKS pods).
AWS NAT Gateway + Internet Gateway.
AWS Route53.
SMTP server or access to a configured AWS SES.
The example AWS IAM policy provided at the end of this document grants all the required permissions for running the Veza deployer.
Bastion host configuration
Self-hosted deployments incorporate a Linux bastion host that Veza employees or customer administrators can access for routine tasks, Veza installations, and upgrades. The bastion can be behind a VPN, or VPC peered with Veza's bastion network depending on the customer's security requirements.
Downloading a custom Veza build
The Veza support team will typically own the steps of downloading the deployer and installing from the jump box. This will involve the following steps:
Typical installation:
The Veza team publishes a link to each new release. To download the file and make it executable:
Log in to the bastion host for the environment to upgrade
Download the custom build:
wget -O veza-{{VERSION}} "<<link>>"Make the file executable:
chmod +x veza-{{VERSION}}Move it to the "deployments" folder:
mv veza-{{VERSION}} deployments/ && cd deployments
Note that build links expire after 12 hours.
Typical maintenance:
A configuration manifest stores all deployment parameters. The Veza team will typically supply a custom configuration file based on the desired environment. You can specify the configuration to use with the '-c' or '--config' flag, for example:
Extract
./veza-{{VERSION}} -c config.yaml extractInstall
./veza-{{VERSION}} -c config.yaml install all --skip-image-pull.
Example AWS IAM policy - Veza deployer
The deployer will need an AWS IAM role granting the following permissions to create and configure AWS resources:
Last updated
