Akeyless Gateway can be deployed on a K8s cluster using the Helm package manager.

Akeyless provides a Helm chart to bootstrap the Gateway deployment.

In the case of k8s deployment, the configuration process takes place before the actual installation.

Prerequisites

An Authentication Method. With access permission to create and manage Secrets, Keys & Targets.
Helm Installed
K8s Installed with K8s metrics server
Minimum 1 vCPU available with 2GB RAM.
Network connection to Akeyless SaaS Core Services from your cluster.

🚧
Note:
Make sure that this server is not globally opened to the public network. Akeyless Gateway requires only connections to Akeyless SaaS Core Services.

The following ports need to be open on the cluster only for internal network access:

Service	Port
Gateway Configuration Manager	8000
Gateway Console	18888
HVP	8200
Akeyless V1 REST API	8080
Akeyless V2 REST API	8081
KMIP Server	5696

Helm Chart configuration

Add the following repository to your Helm repository list:

helm repo add akeyless https://akeylesslabs.github.io/helm-charts
helm repo update

Fetch the values.yaml file from Akeyless repository:

helm show values akeyless/akeyless-api-gateway > values.yaml

Use your favorite editor to set the relevant parameters in the values.yaml file:

vi values.yaml

Authentication

To set your Gateway with a default Authentication Methods to control the level of access your Gateway instance will have inside your Akeyless account.

The following Authentication Methods are supported for K8s deployments:

API Key Authentication

To set your Gateway default authentication based on API Key, provide the relevant Access ID and Access Key :

akeylessUserAuth:
  # adminAccessId is required field, supported types: access_key,password or cloud identity(aws_iam/azure_ad/gcp_gce)
  adminAccessId: <API Key Access ID>
  adminAccessKey: <Access Key>

Save the file and proceed with the installation instructions.

CSP IAM Authentication

While running your K8s cluster inside your cloud environment, you can use AWS IAM, GCP, or Azure Active Directory, using machine-to-machine authentication between Akeyless and your Cloud Service Provider with a list of admin users that will be able to manage your Gateway.

Set the adminAccessId with your IAM Authentication Method Access ID, where you can define a list of users that will be able to mange your Gateway setting the allowedAccessIDs field with any other Access ID of your SAML ,OIDC or an API Key.

AWS IAM

AWS IAM can be used in the following approaches:

Instance IAM Role
Service Account IAM Role

In both cases, provide your AWS IAM Auth Method's Access ID as your adminAccessId, and at least one other Access ID in the allowedAccessIDs list - to provide human users access to config and manage your Gateway:

akeylessUserAuth:
  adminAccessId: < AWS IAM Access ID>
  allowedAccessIDs: []

When working from an AWS instance with an IAM Role associated to it (which is the default state for EKS clusters that leverage the IAM Role of their Node group), nothing else is required - as the Gateway will be leveraging the IAM Role of the AWS instance itself where K8s is running.

Alternatively, you can also leverage an IAM Role assumed by a K8s Service Account in your Cluster. For that you must either create an IAM Role bound to a K8s Service Account, or use an existing IAM role for annotating the Service Account in the Gateway's values.yaml helm-chart:
Set the serviceAccountName with the desired Kubernetes Service Account name, and set its eks.amazonaws.com/role-arn annotation to the ARN of the IAM Role in question (which is constructed using the following format: arn:aws:iam::<AWS-Account-ID>:role/<IAM-Role-Name>).

You can also create a new Service Account by simply setting the create field to true, so the serviceAccountName you defined will be created upon deployment. Furthermore, if the serviceAccountName is left empty, by default - the chart will create a new Service Account called <release name>-akeyless-gateway.
Make sure to set the required role-arn annotation to connect your IAM Role with the Service Account in any of the scenarios.

deployment:
  annotations: {}
  labels: {}
  service_account:
    create: true
    serviceAccountName: <EKS SA name>
    annotations:
        eks.amazonaws.com/role-arn: arn:aws:iam::<AWS Account ID>:role/<IAM Role Name>
akeylessUserAuth:
  adminAccessId: < AWS IAM Access ID>
  allowedAccessIDs: []

Save the file and proceed with the installation instructions.

GCP GCE

Google Kubernetes Engine (GKE) can run Akeyless Gateway in its secured and managed Kubernetes service in standard or autopilot mode.

Deploying Akeyless Gateway via the Helm chart using the authentication between your Gateway and Akeyless SaaS using our GCP Authentication method can be done using the GCP Workload Identity mechanism.

Workload Identity allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) Service Accounts to access Google Cloud services. Workload Identity is enabled by default on Autopilot clusters.

Follow the GKE workload identities guide to enable GKE workload identities on your cluster.

Create a Kubernetes service account for Akeyless Gateway to use. You can also use the default Kubernetes service account in the default or any existing namespace.

Use the existing IAM service account as provided in your GCP GCE auth method.

👍
Note
When authenticating from a pod inside a Google Kubernetes Engine (GKE) cluster using GKE Workload Identity enabled, any bounded rules other than Bound Service Accounts will not apply. GKE Workload Identity conceals metadata information about the running instance.
To work with the GKE Workload Identity you must configure only the Bound Service Accounts field in your GCP Auth Method.

Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.

Replace the following:
PROJECT_ID: your Google Cloud project ID.
GSA_NAME : the name of your IAM service account.
GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account.
KSA_NAME: the name of your new Kubernetes service account.
NAMESPACE: the name of the Kubernetes namespace for the service account.

gcloud iam service-accounts add-iam-policy-binding [email protected]_PROJECT.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"

Annotate the Kubernetes service account with the email address of the IAM service account.

kubectl annotate serviceaccount KSA_NAME \
    --namespace NAMESPACE \
    iam.gke.io/[email protected]_PROJECT.iam.gserviceaccount.com

Set the relevant K8s serviceAccountName or leave it empty to use the default K8s Service Account, update the annotations, and enable the nodeSelector to schedule the workloads on nodes that use Workload Identity and to use the annotated Kubernetes service account.

And set your GCP GCE Access ID as your adminAccessId and at least one another Access ID in the allowedAccessIDs list, to provide human users access to config and manage your Gateway:

deployment:
  annotations: {}
  labels: {}
  service_account:
    create: false
    serviceAccountName: <GKE SA Name>
   annotations:
        iam.gke.io/gcp-service-account: <GCP SA Name>
  nodeSelector:
         iam.gke.io/gke-metadata-server-enabled: "true"    
akeylessUserAuth:
  adminAccessId: < GCP GCE Access ID>
  allowedAccessIDs: []

📘
NodeSelector
For Autopilot clusters, omit the nodeSelector field. Autopilot rejects this nodeSelector because all nodes use Workload Identity.

Save the file and proceed with the installation instructions.

Azure Active Directory

Azure AD authentication is provided to AKS clusters with OpenID Connect. OpenID Connect is an identity layer built on top of the OAuth 2.0 protocol. Akeyless treats Azure as a trusted third party and verifies entities based on a JWT signed by the Azure Active Directory for the configured tenant.

Set your Azure Active Directory Access ID as your adminAccessId and at least one another Access ID in the allowedAccessIDs list, to provide human users access to config and manage your Gateway:

akeylessUserAuth:
  # adminAccessId is required field, supported types: access_key,password or cloud identity(aws_iam/azure_ad/gcp_gce)
  adminAccessId: < Azure AD Access ID>
  allowedAccessIDs: []

Save the file and proceed with the installation instructions.

Universal Identity

Akeyless support Universal Identity authentication method for on-premise K8s clusters environments, eliminating the secret zero problems within your config files.

Set the adminUIDInitToken field with your initial root Universal Identity token. Set the rotation interval and choose either to generate a child token for your pods using uidCreateChildTokenPerPod field.

akeylessUserAuth:
  adminUIDInitToken: u-xxxxxxxxxxxx
universalIdentity:
  # interval im minutes, if empty the token will be rotated in token-ttl/3  max=10 
  uidRotationInterval: "5m" 
  uidCreateChildTokenPerPod: "disable"

Save the file and proceed with the installation instructions.

Certificates

To set your Gateway default authentication based on Certificates provide the relevant Access ID as your adminAccessId, with a base64 encoded Certificate, and Certificate Key, with at least one another Access ID in the allowedAccessIDs list, to provide human users access to config and manage your Gateway:

akeylessUserAuth:
  adminAccessId: <Access ID>
  adminBase64Certificate: <Base64 Certificate>
  adminBase64CertificateKey: <Base64 Cert key>
  allowedAccessIDs: []

Alternatively, you can provide the certificate and your certificate key as k8s secrets, as described in this guide.

Gateway Admins

To support local management of your Gateway configuration, you can set a list of allowed Access ID that will be able to log in and manage your Gateway. This setting can also work with sub-claims (when a shared authentication method is used), for example:

allowedAccessIDs:
 - p-yyyyyy [email protected]
 - p-yyyyyy [email protected]
 - p-yyyyyy group=Devops

In this case,p-yyyyyy is your SAML or OIDC Access ID, where a user that at least matches one sub-claim attribute, will be authorized to access the Gateway:

In our example, [email protected] and [email protected] will be authorized, and any member of group=Devops will also be authorized.

In this case, the Access ID belongs to the authentication method created for the certain Identity Provider.
If you don't specify the sub-claims, every user authenticated by this IDP will be able to log in to the Gateway with admin privileges.

To work with API Key as an allowedAccessIDs simply provide your API Key Access ID.

You may also edit this parameter on your console, by going to the Gateways tab and selecting the desired Gateway. On the right of the screen, you will see the Gateway details, including allowed access IDs. Selecting to edit this parameter will allow you to remove existing allowed IDs or to allow an existing Authentication Method from your account to access the Gateway with optional Sub-Claims.

Installation

To install the Gateway using the edited values.yaml file, run the following command:

helm install gw akeyless/akeyless-api-gateway -f values.yaml

Check if the pods are up and running:

kubectl get pod

NAME                                       READY   STATUS    RESTARTS       AGE
gw-akeyless-api-gateway-6554f7c66c-56fgs   1/1     Running   0                          5s
gw-akeyless-api-gateway-6554f7c66c-7jt8r   1/1     Running   0              5s

Gateway on K8s

Prerequisites

🚧
Note:

Helm Chart configuration

Authentication

API Key Authentication

CSP IAM Authentication

AWS IAM

GCP GCE

👍
Note

📘
NodeSelector

Azure Active Directory

Universal Identity

Certificates

Gateway Admins

Installation

Prerequisites

🚧Note:

Helm Chart configuration

Authentication

API Key Authentication

CSP IAM Authentication

AWS IAM

GCP GCE

👍Note

📘NodeSelector

Azure Active Directory

Universal Identity

Certificates

Gateway Admins

Installation

🚧
Note:

👍
Note

📘
NodeSelector