Infrastructure & Permissions for e6data
Required Infrastructure
The following infrastructure required to run e6data must be created before setup:
Azure Storage Account and a blob Container
Required Permissions
App registration with specified permissions for e6data control plane to access the AKS cluster and other components to manage endpoints(add link for e6data endpoints here).
Managed identity for the e6data engine to access the query data.
Azure Storage Account and a blob Container
An Azure Storage Account with a Blob container is required to store data necessary for the operation of the e6data workspace, including service logs, query results, state information, and other operational data.
Steps to create these resources using Azure CLI:
Before proceeding with the commands, define the key variables that will be used throughout the process:
Set up variables:
Create the Azure Storage Account:
Create the Blob container within the Storage Account:
After running these commands:
You will have a Storage Account named
e6dataworkspace<random_string>
.Within this Storage Account, there will be a private Blob container named
e6data-workspace-data
.This container can be used to store all the necessary data for your e6data workspace operations.
Required Permissions
Required Azure Permissions for e6data Control Plane
To enable proper functioning of the e6data control plane with Azure Kubernetes Service (AKS), the following permissions are required:
AKS Cluster Access:
"Microsoft.ContainerService/managedClusters/listClusterUserCredential/action"
"Microsoft.ContainerService/managedClusters/read"
These permissions allow secure access to the AKS cluster by obtaining the necessary kubeconfig file.
Network Resource Access:
"Microsoft.Network/loadBalancers/read"
"Microsoft.Network/publicIPAddresses/read"
"Microsoft.Network/networkInterfaces/delete"
"Microsoft.Network/networkInterfaces/read"
These permissions grant read access to load balancers and public IP addresses, which is essential for creating e6data endpoints.
Implementation
To acquire these permissions, we use a User Assigned Managed Identity with a federated identity credential. This setup allows for secure and controlled access to the necessary Azure resources for e6data operations by leveraging the managed identity’s client ID for authentication.
Create an User-Assigned Managed Identity:
Set up variables:
Create an identity:
IDENTITY_NAME="${WORKSPACE_NAME}-identity-${RANDOM_STRING}": Sets a variable for the identity name, using the workspace name and a random string for uniqueness.
az identity create: Creates the user-assigned managed identity in Azure.
--name $IDENTITY_NAME: Specifies the name of the identity.
--resource-group "$RESOURCE_GROUP_NAME": The resource group where the identity will be created.
--location "$LOCATION": The Azure region where the identity will be created.
--tags "$TAGS": Adds tags for organizational purposes (optional).
--query id -o tsv: Retrieves the ID of the created identity in plain text format.
Create a Federated Identity Credential
To create a federated identity credential with the specified parameters, follow these steps:
This federated identity credential now links your managed identity to your Cognito configuration, enabling secure authentication without directly storing secrets.
Retrieve the Identity's Principal ID:
az identity show: Fetches details of the created identity.
--id $IDENTITY_ID: Uses the identity ID from the previous command.
--query principalId -o tsv: Extracts the principal ID (the unique identifier for the identity) in plain text format.
Create custom role for AKS credentials:
Create custom role for load balancer and public IP:
Assign custom AKS role to the managed identity:
Assign custom load balancer role to the managed identity:
Remember to replace placeholders like $WORKSPACE_NAME
, $RANDOM_STRING
, $RESOURCE_GROUP_NAME
, and $AKS_CLUSTER_NAME
with your actual values.
These steps create an Azure AD application, managed identity, federated credential, custom roles, and necessary role assignments as described in your Terraform configuration. Note that some of these operations, especially those involving custom role creation and assignment, may require elevated permissions in your Azure AD and subscription.
Creating User-Assigned Managed Identity for e6data Engine's Blob Storage Access
This setup allows the e6data engine to securely access blob storage using Azure's managed identity, without the need for storing credentials within the pods. The Workload Identity feature in AKS facilitates the seamless use of the managed identity by the e6data engine, ensuring secure and efficient data access for querying purposes. The e6data engine requires specific access roles for different storage accounts:
Log Storage Account:
Role: "Storage Blob Data Contributor"
Purpose: Allows e6data to write and manage logs in the dedicated storage account created to store data required for the operation of the e6data workspace.
Data Storage Accounts:
Role: "Storage Blob Data Reader"
Purpose: Enables e6data to read data from the storage accounts containing the data buckets on which queries are executed. below are the steps to do it
Create a user-assigned managed identity:
Create a federated identity credential:
Assign Storage Blob Data Reader role to the managed identity for each container: Before running these commands, make sure to replace the following placeholders with your actual values:
DATA_STORAGE_ACCOUNT_NAME
DATA_STORAGE_ACCOUNT_RG
LIST_OF_CONTAINERS
(this should be an array of container names)
Assign Storage Blob Data Contributor role to the managed identity for the e6data managed storage account:
These steps will create an user-assigned managed identity, a federated credential for AKS workload identity, and assign the necessary roles to access storage accounts and containers.
Deploying Azure Key Vault to Kubernetes (akv2k8s
) using Helm
akv2k8s
) using HelmThe following section provides a step-by-step guide to deploying the akv2k8s
(Azure Key Vault to Kubernetes) Helm chart into your Azure Kubernetes Service (AKS) cluster. This deployment allows seamless integration between Azure Key Vault and Kubernetes, enabling your workloads to securely fetch secrets directly from Azure Key Vault.
Prerequisites
Before starting the deployment, ensure the following prerequisites are met:
Helm Installed: Helm should be installed on your local machine. You can verify this by running
helm version
.Kubeconfig Access: Ensure you have access to your Kubernetes cluster via your kubeconfig file, typically located at
~/.kube/config
.
Step-by-Step Deployment Instructions
Step 1: Add the Helm Repository
Start by adding the Helm repository containing the akv2k8s
chart:
This command adds the spv-charts
repository to Helm, where the akv2k8s
chart is hosted.
Step 2: Update Helm Repositories
Next, update your Helm repositories to ensure you have access to the latest charts:
Step 3: Install the akv2k8s
Chart
Install the akv2k8s
chart into the kube-system
namespace of your AKS cluster:
akv2k8s
: The release name for this deployment.spv-charts/akv2k8s
: Specifies the repository and chart name.--namespace kube-system
: Deploys the release into thekube-system
namespace.
Step 4: Verify the Installation
To confirm the successful installation of the chart, list the Helm releases in the kube-system
namespace:
You should see the akv2k8s
release listed among your installed Helm charts.
Step 5: Monitor the Pods
Check the status of the pods created by the akv2k8s
deployment:
This command will show the running status of the pods related to akv2k8s
in your cluster.
Summary of Commands
Key Vault Access for the akv2k8s
Tool
akv2k8s
ToolTo allow the akv2k8s
tool to access the Azure Key Vault and retrieve the certificates necessary for TLS and Gateway connectivity, you need to assign the "Key Vault Certificate User" role to your AKS cluster’s kubelet identity. This ensures that the tool can securely fetch the required certificates.
Here are the steps to assign the "Key Vault Certificate User" role to your AKS cluster's kubelet identity using the Azure CLI:
Step-by-Step Guide
1. Log in to Azure:
2. Set your subscription:
Replace <your-subscription-id>
with your Azure subscription ID.
3. Get the Key Vault ID:
Replace <keyvault-name>
and <resource-group-name>
with your Key Vault name and resource group name. This will retrieve the Key Vault's ID.
Save the output, as you will need it for the --scope
parameter.
4. Get the kubelet identity's principal ID:
Replace <aks-cluster-name>
and <resource-group-name>
with your AKS cluster name and resource group name. This will retrieve the kubelet identity's principal ID.
Save the output, as you will need it for the --assignee
parameter.
5. Assign the "Key Vault Certificate User" role:
Replace <keyvault-id>
and <principal-id>
with the values retrieved in the previous steps.
Last updated