Setup using Terraform in AWS
If you prefer to setup all the necessary infrastructure for e6data automatically, Terraform scripts and instructions to use them are provided below.
Prerequisites
Before you begin, ensure that you have the following prerequisites in place:
An AWS account with appropriate permissions to create and manage resources.
A local development environment with Terraform installed.
Create the e6data Workspace
Login to the e6data Console
Navigate to
Workspaces
in the left-side navigation bar or clickCreate Workspace
Select AWS as the Cloud Provider.
Proceed to the next section to deploy the Workspace.
Setup e6data
Using the Terraform script, the e6data Workspace will be deployed inside an Amazon EKS Cluster. The subsequent sections will provide instructions to edit two Terraform files required for the deployment:
If an Amazon EKS cluster is not available, please follow these instructions.
If Terraform is not installed, please follow these instructions.
Download e6data Terraform Scripts
Please download/clone the e6x-labs/terraform
repo from Github.
Configure provider.tf
The Amazon Web Services (AWS) provider in Terraform allows you to manage AWS resources efficiently. However, before utilizing the provider, it's crucial to configure it with the appropriate credentials.
Extract the scripts downloaded in the previous step and navigate to the aws_workspace
folder.
Edit the provider.tf
file according to your requirements. Please refer to the official Terraform documentation to find instructions to use the authentication method most appropriate to your environment.
Specifying AWS S3 Bucket for Terraform State file
Specifying an AWS S3 bucket for Terraform state files enhances security, provides durability, and supports collaborative infrastructure management. It isolates the state from resources, ensures high availability, and facilitates teamwork, offering versioning for easy rollback and auditability.
To specify an AWS S3 bucket for storing the Terraform state when using AWS as the provider, add the following configuration to the Terraform script replace <BUCKET_TO_STORE_TF_STATE>
with the target S3 bucket name to store the Terraform state.
The key
parameter specifies the name of the state file within the bucket. It is set to "terraform/state.tfstate"
, but it can be edited as required.
Make sure that the IAM user or role associated with the provided access credentials has the necessary permissions to read from and write to the specified S3 bucket.
For more information and to explore additional backend options, refer to the Terraform Backend Configuration documentation.
Configuration Variables in terraform.tfvars
File
terraform.tfvars
FileThe terraform.tfvars
file contains the following variables that need to be configured before executing the Terraform script.
Please update the values of these variables in the terraform.tfvars
file to match the specific configuration details for your environment:
When using an existing EKS Cluster with Karpenter, please ensure the Karpenter controller role includes the following permissions:
The Karpenter controller should have access to the e6data nodepool and EC2 nodeclass.
The
iam:PassRole
permission must be assigned to the e6data Karpenter node role.
The identifiers for the e6data nodepool, EC2 nodeclass and Karpenter node role will be available in the Terraform outputs.
Execution Commands
Once you have configured the necessary variables in the provider.tf
& terraform.tfvars
files, you can proceed with the deployment of the e6data workspace. Follow the steps below to initiate the deployment:
Navigate to the directory containing the Terraform files. It is essential to be in the correct directory for the Terraform commands to execute successfully.
Initialize Terraform:
terraform init
Generate a Terraform plan and save it to a file (e.g.,
e6.plan
):
terraform plan -var-file="terraform.tfvars" --out="e6.plan"
The -var-file
flag specifies the input variable file (terraform.tfvars
) that contains the necessary configuration values for the deployment.
Review the generated plan.
Apply the changes using the generated plan file:
terraform apply "e6.plan"
This command applies the changes specified in the plan file (e6.plan) to deploy the e6data workspace in your environment.
Make note of the values returned by the script.
Return to the e6data Console and enter the values returned in the previous step.
Deployment Overview and Resource Provisioning
This section provides a comprehensive overview of the resources deployed using the Terraform script for the e6data workspace deployment.
Only the e6data engine, residing within the customer account has permission access to data stores.
The cross-account role does not have access to data stores, therefore access to data stores from the e6data platform is not possible.
All roles and role-bindings are created only within the e6data namespace.
Permissions
Engine Permissions
The e6data Engine which is deployed inside the customer boundary, requires the following permissions:
glueReadOnlyAccess to read Glue catalogs:
ListBucket:
ReadE6dataBucket:
Cross-account Role Permissions
ListBucket:
ReadWriteE6dataBucket:
describeEKSCluster:
Permissions to create endpoint related resources
Monitoring Permissions
The e6data microservices used for monitoring the cluster & reporting metrics require these permissions.
Resources Created
VPC and Subnets
The network module creates a Virtual Private Cloud (VPC) within the specified CIDR range provided by the customer, establishing public and private subnets across all available Availability Zones (excluding those mentioned in the "excluded_az" input). In this setup, a single Internet Gateway (IG) and a single Network Address Translation (NAT) Gateway are deployed, serving all the Availability Zones. Public subnets are designed for resources requiring direct internet access, while private subnets use the shared NAT Gateway to enable secure outbound connectivity. This resource design ensures efficient networking while minimizing costs by centralizing the IG and NAT Gateway resources across the VPC's Availability Zones, promoting security and scalability for the customer's AWS environment.
EKS Cluster
A new EKS cluster will be created within the previously created VPC. This EKS cluster will have OIDC (OpenID Connect) configured to enhance security for user and service authentication within the cluster. Additionally, two IAM roles will be generated to manage permissions within the cluster:
"iam_eks_cluster_role": This role permits the EKS cluster to assume its identity, allowing it to interact securely with various AWS services and resources.
"iam_eks_node_role": This role is utilized by the EKS worker nodes to gain similar permissions, allowing them to assume this role for executing tasks and operations within the cluster.
Karpenter
Along with creating the EKS cluster, we will also configure Karpenter.
Karpenter is an open-source Kubernetes autoscaler that automatically provisions the right-sized compute resources in response to changing application loads within a Kubernetes cluster.
Auto-scaling is necessary to automatically increase the number of executors when the e6data engine identifies heavy query loads.
The "scale-out" autoscaling strategy is effective for managing concurrent workloads. Karpenter is generally deployed in your cluster using a Helm chart or YAML manifest.
For Karpenter to function effectively, it needs permissions to inspect and modify EC2 instances and manage node groups within the cluster. This requires providing Karpenter with the appropriate AWS Identity and Access Management (IAM) roles and policies.
An SQS queue is configured to manage node interruption messages for Karpenter within an EKS cluster. The setup includes IAM policies that permit AWS services to send messages to this queue. CloudWatch Event Rules are used to capture a variety of AWS events, such as Spot Instance Interruption Warnings, AWS Health Events, EC2 Instance Rebalance Recommendations, and EC2 Instance State-change Notifications. These events are directed to the SQS queue, allowing Karpenter to proactively handle node interruptions, ensuring high availability and minimizing workload disruptions.
ALB Ingress controller
AWS ALB Ingress Controller will be deployed in the EKS cluster using helm release resource in terraform.
The AWS ALB Ingress Controller is an open-source project that simplifies the management of AWS Elastic Load Balancers (ALBs and NLBs) within Kubernetes clusters. It provisions AWS load balancers automatically based on Kubernetes Ingress and Service resources, allowing users to define routing and load balancing configurations effortlessly.
AWS S3 Bucket
The Terraform script sets up an AWS S3 bucket with enhanced security and access controls to store the query results. It enables versioning, server-side encryption, and logging for the bucket. Public access is blocked, and the bucket ACL is set to private to ensure secure access to the bucket contents.
Roles & Permissions Created
Configuring IAM Policies and Roles for e6data Engine with Federated Credentials:
The Terraform script defines policies for AWS Glue and S3 access and creates an IAM role with federated credentials. This enables the e6data engine to securely interact with Glue and read from designated S3 buckets in AWS.
Cross Account Role for e6data Control Plane:
It also sets up a cross-account IAM role that grants read/write access to the workspace S3 bucket and permission to describe the EKS cluster. This role enables secure interaction and allows the e6data control plane to assume the role based on the AWS OIDC role.
Helm Chart Deployment:
The Helm chart deployed using the Terraform script creates roles and role bindings in the EKS cluster for the e6data control plane user.
These roles and role bindings define the permissions and access levels for the control plane user within the cluster, allowing it to perform specific actions and interact with resources as required by the e6data workspace.
The defined permissions include the ability to manage various resources such as pods, nodes, services, ingresses, configmaps, secrets, jobs, deployments, daemonsets, statefulsets, and replicasets.
By deploying these cluster roles through the Helm release, the e6data control plane user is equipped with the necessary permissions to effectively manage and interact with the resources within the cluster, enabling seamless operation and configuration of the e6data platform.
To ensure proper communication between the Terraform script and the EKS cluster, it is essential to retrieve the existing "aws-auth" ConfigMap in the "kube-system" namespace using the data "kubernetes_config_map_v1" "aws_auth_read"
block. This allows the script to access and read the configuration map for further usage.
However, please note that if you encounter an "unauthorized" error while retrieving the ConfigMap, it may indicate that the IAM role or user executing the Terraform script does not have sufficient privileges to access and modify the ConfigMap.
When an Amazon EKS cluster is created, the IAM principal that creates the cluster is automatically granted
system:masters
permissions in the cluster's RBAC configuration.To grant additional IAM principals the ability to interact with a cluster, you need to edit the aws-auth ConfigMap within Kubernetes and create a Kubernetes rolebinding or clusterrolebinding with the name of a group that you specify in the aws-auth ConfigMap. You can find the detailed steps and further information in the AWS documentation: Add User or IAM Role to a Cluster.
By granting the appropriate permissions to access and modify the "aws-auth" ConfigMap, you will resolve the "unauthorized" error and ensure seamless communication between the Terraform script and the EKS cluster during the deployment of the e6data workspace.
Last updated