Secure Remote Access Bastion

The Akeyless Secure Remote Access Bastion provides secure remote access to resources using Just In Time credentials (dynamic, rotated secrets, and SSH certificates).

This chart bootstraps the Secure Remote Access Bastion deployment on a Kubernetes cluster using the Helm package manager.



When using SSH sessions behind a load balancer such as ELB, the session can be closed due to an idle connection timeout, so we recommend increasing it to a reasonably high value or even unlimited.

e.g., when running on AWS with ELB:


Currently, the chart requires a storage class with the ReadWriteMany access mode.

Since a storage class is more environment-specific, you will need to provide one before proceeding. In addition, please provide a PersistentVolumes with persistentVolumeReclaimPolicy: retain and reference those PVs in the chart values file

    name: share-storage
    storageClassName: "efs-sc"
      - ReadWriteMany
    persistentVolumeReclaimPolicy: Retain
    annotations: {}
      - dir_mode=0650
      - file_mode=0650
    size: 2Gi

e.g., when running on AWS with EKS:

Horizontal Auto-Scaling

Horizontal auto-scaling is based on the HorizontalPodAutoscaler object.
For it to work correctly, the Kubernetes metrics server must be installed in the cluster -



To enable Secure Remote Access features you will have to get an access key to Akeyless private repository. Please contact your Account Manager for more details.

Installing the Chart

Add Akeyless helm charts repository to your Helm repository list:

helm repo add akeyless
helm repo update

The values.yaml file holds default values. Copy the file from:

Or run the following helm command to generate the values file locally:

helm show values akeyless/akeyless-sra > values.yaml


To connect to Akeyless private repository, set the dockerRepositoryCreds field to access the Akeyless internal image and the relevant apiGatewayURL to point your Gateway REST API port 8080

## Global ##

The Secure Remote Access Bastion should be set with a privileged AccessID with Read and list permissions, to fetch the relevant secret on behalf of your users, set the privilegedAccessfield with the relevant AccessID as described in the Authentication section of this page.

Users can have only list permissions on their secrets. Upon successful authentication against your IDP, the bastion will fetch the requested secret from Akeyless and will inject them directly for your users transparently.
To control who will be the relevant users that will be allowed to request access from the Akeyless Bastion, set the allowedAccessIDs field with a list of AccessIDs that will be authorized to request access.

  accessID: "<Access ID>"
  allowedAccessIDs: []

To provide just-in-time native CLI access for your users using Keyless SSH set the CAPublicKey field with the matching public key of the key you used to create the SSH Certificate Issuer

## Default values for akeyless-ssh-bastion ##
# Enable akeyless-ssh-bastion. Valid values: true/false.
  enabled: true
    CAPublicKey: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCu8RWf5bFDlLhPljsYEKFQAt6cFLdAVOy"



If you don't have an SSH certificate ready, please follow this guide on creating SSH Cert issuer with Akeyless Platform and set your CA Public key in the chart values.


The following Authentication Methods are supported:

API Key Authentication

To set your Bastion default authentication based on API Key, set the accessID and the matching accessKey with a list of allowedAccessIDs that will be authorized to request access:

  accessID: "<API Key Access ID>"
  accessKey: "<Access Key>"
    - p-xxxxxxx

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 allowed AccessIDs that will be authorized to request access.


AWS IAM can be used in the following approaches:

  • Instance IAM Role

  • Service Account IAM Role

While working with an IAM Role associated with the instance himself, you can simply provide your AWS IAM Access ID as your accessID, with a list of allowedAccessIDs that will be authorized to request access:

  accessID: "<AWS IAM Access ID>"
    - p-xxxxxxx

To Work with an IAM Role based on Service Account, in K8s, you define the IAM role to associate with a Service Account in your cluster by adding the relevant annotation to the Service Account.

To annotate a Service Account with an IAM role, set the serviceAccountName with your existing Kubernetes Service Account name and replace arn:aws:iam::AWS_Accound_ID:role/iam-role-name with your AWS account ID and iam-role-name with the name of your existing AWS Identity and Access Management (IAM) role.

  accessID: "<AWS IAM Access ID>"
    - p-xxxxxxx    
    create: false
    serviceAccountName: <EKS SA name>
    annotations: arn:aws:iam::<AWS Account ID>:role/<IAM Role Name>

Alternatively, you can create a new Service Account, simply set the create field with true and set the new serviceAccountName. If left empty by default, the chart will create a new Service Account called <release name>
Make sure to set the right annotation to connect your IAM Role with the newly created Service Account.


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

Deploying Akeyless Bastion via the Helm chart using the authentication between your Bastion 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 Bastion 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.



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 with bounded rules, please 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] \
    --role roles/iam.workloadIdentityUser \
    --member "[NAMESPACE/KSA_NAME]"

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

kubectl annotate serviceaccount KSA_NAME \
    --namespace NAMESPACE \[email protected]

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.

  accessID: "<GCP GCE Access ID>"
    - p-xxxxxxx    
    create: false
    serviceAccountName: "<GKE SA Name>"
   annotations: "<GCP SA Name>"
  nodeSelector: "true"     
  gcpAudience: ""

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 accessID with the matching service principal azureobjectID', with a list of allowedAccessIDs` that will be authorized to request access:

  accessID: "Azure AD Access ID"
  azureObjectID: ""
    - p-xxxxxxx


helm install <RELEASE NAME> akeyless/akeyless-sra -f values.yaml

Verify that both ssh-sra-akeyless and web-sra-akeyless pods are up and running.



Akeyless supports session termination, which can be configured as part of this chart deployment.
To enable session termination, please set your Okta\Keycloak apiURL and apiToken
under sessionTermination section.

Did this page help you?