akeyless/zero-trust-bastion-test repository overview

⁠AKEYLESS Zero Trust Bastion

Akeyless Zero Trust Bastion provides zero trust access to remote resources using Akeyless JIT credentials (dynamic secrets and SSH certificate issuers).

⁠Getting started

To run Akeyless Zero Trust Bastion, simply run the container:

docker run --rm -itd \
    -p 8888:8888 \
    akeyless/zero-trust-bastion

The service will be available on port :8888 (or any other port you chose to map).

⁠Configure

Some configuration is supported to extend the default functionality.

⁠Using Akeyless API Gateway

By default, Akeyless Zero Trust Bastion communicates with Akeyless Vault using https://api.akeyless.io. If your deployment includes Akeyless API Gateway, you can use it to access your remote resources:

docker run --rm -itd \
    -p 8888:8888 \
    -e AKEYLESS_URL=https://akeyless.mydomain.com \
    akeyless/zero-trust-bastion

In this case, https://akeyless.mydomain.com⁠ is an address of Akeyless API exposed by Akeyless API Gateway (:8081 by default).

Please not that this doesn't have to be the same API Gateway that has dynamic secret producers running. It can be any publicly available API Gateway.

⁠Using privileged credentials

For enhanced security and secrets isolation, there is a way to grant Akeyless Zero Trust bastion read access to just-in-time credentials, while the actual users have only list access to them.

Make sure to grant privileged auth method sufficient permissions (read ability) on required credentials. Actual end users can have only list ability on the same items, so they will never get the actual values, Akeyless Zero Trust Bastion will do that on their behalf.

Not using this option will allow end users to use their own credentials to access the secrets. In this case, read ability must be available to the end user.

Currently, AWS IAM, Azure AD, GCP and API Key authentication methods are supported for privileged access.

⁠Zero-trust RDP access with "Fixed user" feature

Historically, RDP producers that use "Fixed user" feature rely on SAML sub-claims to figure out Windows username to use. Since it would be problematic when using privileged credentials (privileged credentials don't have any RDP usernames built in), Zero-Trust Bastion will use rdp_username sub-claim from end users' credentials. If you use a different sub-claim, it should be specified at deployment time using RDP_USERNAME_SUB_CLAIM environment variable, for example:

docker run ... -e RDP_USERNAME_SUB_CLAIM=custom_user # default: rdp_username

⁠AWS IAM privileged credentials

To use privileged credentials of type AWS IAM, set PRIVILEGED_ACCESS_ID environment variable when setting up an Akeyless Zero Trust Bastion container in AWS:

docker run ... -e PRIVILEGED_ACCESS_ID=p-12341234ab

⁠Azure AD privileged credentials

To use privileged credentials of type Azure AD, set PRIVILEGED_ACCESS_ID environment variable when setting up Akeyless Zero Trust Bastion container in Azure:

docker run ... -e PRIVILEGED_ACCESS_ID=p-12341234ab

To authenticate using a particular Azure Object ID, set an additional environment variable:

docker run ... -e AZURE_OBJECT_ID=<object-id>

⁠GCP privileged credentials

To use privileged credentials of type GCP, set PRIVILEGED_ACCESS_ID environment variable when setting up Akeyless Zero Trust Bastion container in GCP:

docker run ... -e PRIVILEGED_ACCESS_ID=p-12341234ab

By default, akeyless.io audience is used during GCP authentication. If you used a different value during GCP Auth Method setup, set GCP_AUDIENCE environment variable accordingly:

docker run ... -e GCP_AUDIENCE=<audience> # default: akeyless.io

⁠API Key privileged credentials

To use privileged credentials of type API Key, set PRIVILEGED_ACCESS_ID and PRIVILEGED_ACCESS_KEY environment variables when setting up Akeyless Zero Trust Bastion container:

docker run ... \
        -e PRIVILEGED_ACCESS_ID=p-12341234ab \
        -e PRIVILEGED_ACCESS_KEY=something-something-secret-key

⁠Limiting access to specific access IDs

When using privileged credentials, it is recommended to explicitly specify which access IDs are allowed to access the secrets protected with privileged credentials.

By default, all access IDs are accepted. To specify access IDs, use ALLOWED_ACCESS_IDS environment variable:

ALLOWED_ACCESS_IDS=p=000011112222
ALLOWED_ACCESS_IDS=p=000011112222,p-aabbccddeeff

⁠Exposing RDP session recordings

Every RDP session is recorded and saved inside the container. To access the recordings, mount a local directory to /home/akeyless/recordings path inside the container:

docker run --rm -itd \
    -p 8888:8888 \
    -v $PWD/recordings:/home/akeyless/recordings \
    akeyless/zero-trust-bastion

In this case, recordings folder will be created in your current working directory, and all sessions recordings will be available in it at the end of each session.

Please note: recordings of RDP sessions consume significant storage space. Make sure to setup backup/cleanup process to ensure smooth experience.

⁠Automatic upload of recordings to S3/Azure Blob Storage

It is possible to automatically upload session recordings to S3 in your AWS account or to Blob storage in your Azure account.

For each cloud, there are two options:

1. Deploy Akeyless Zero Trust Bastion on AWS/Azure machine, and use IAM roles for Amazon⁠/Azure⁠ with sufficient permissions to upload new files into an S3 bucket/Azure Blob Storage of your choice. Then, provide AWS_REGION, AWS_S3_BUCKET and AWS_S3_PREFIX (for Amazon)/ AZURE_STORAGE_ACCOUNT and AZURE_STORAGE_CONTAINER_NAME (for Azure) environment variables when creating a new container. All recordings will be uploaded into specified storage:

docker run --rm -itd \
    -p 8888:8888 \
    -e AWS_REGION=us-east-1 \
    -e AWS_S3_BUCKET=my-bucket \
    -e AWS_S3_PREFIX=akeyless-zero-trust-bastion \
    akeyless/zero-trust-bastion

docker run --rm -itd \
    -p 8888:8888 \
    -e AZURE_STORAGE_ACCOUNT=srarecords \
    -e AZURE_STORAGE_CONTAINER_NAME=akeyless-zero-trust-bastion \    
    akeyless/zero-trust-bastion

1. Alternatively, run the container with explicit credentials. This way is not recommended, but still possible:

docker run --rm -itd \
    -p 8888:8888 \
    -e AWS_ACCESS_KEY_ID=******************** \
    -e AWS_SECRET_ACCESS_KEY=**************************************** \
    -e AWS_REGION=us-east-1 \
    -e AWS_S3_BUCKET=my-bucket \
    -e AWS_S3_PREFIX=akeyless-zero-trust-bastion \
    akeyless/zero-trust-bastion

docker run --rm -itd \
    -p 8888:8888 \
    -e AZURE_TENANT_ID=******************** \
    -e AZURE_CLIENT_ID=******************** \
    -e AZURE_CLIENT_SECRET=**************************************** \
    -e AZURE_STORAGE_ACCOUNT=srarecords \
    -e AZURE_STORAGE_CONTAINER_NAME=akeyless-zero-trust-bastion \    
    akeyless/zero-trust-bastion

Regardless of the method you choose, in the end of each session, recordings will be uploaded to S3 in addition to being available under /home/akeyless/recordings (via a volume mount to your local directory).

Upload status is reflected in container logs. Make sure to check them for errors if something seems wrong.

⁠Build

Everything is packed into a single Docker container. To build it locally, clone this project and run:

docker build --tag akeyless/zero-trust-bastion .