Set Up Cloud Secure Link

This page describes how to download the Cloud Secure Link client artifacts, deploy the client, and connect your self-hosted resources to Appian Cloud.

Prerequisites

Client installation requirements

Ensure your organization has the ability to install and enable the Cloud Secure Link client artifacts within your infrastructure.

You can optionally deploy multiple replicas of a Cloud Secure Link client for high availability. Ensure you understand the requirements to prevent identity conflicts caused by the sharing of files between client replicas.

System requirements

Appian requires that you deploy Cloud Secure Link using Docker or Kubernetes. Appian strongly recommends Kubernetes. Standalone Docker deployment is supported but not recommended due to the manual nature of container updates.

Networking requirements

• The Cloud Secure Link client must be able to send HTTPS traffic to the Cloud Secure Link service over the public internet. The client cannot connect through a non-transparent proxy.
• The Cloud Secure Link client must be able to connect to the self-hosted resource.
• Appian recommends deploying the Cloud Secure Link client as close as practical to the self-hosted resource to simplify network configuration.
• Cloud Secure Link provides an additional layer of encryption for traffic between Appian Cloud and the Cloud Secure Link client. This is not a replacement for application-level encryption (such as TLS). Application-level encryption is strongly recommended for all connections that use Cloud Secure Link.

Register your client in the Admin Console

Before you install the Cloud Secure Link client, you must register the client in the Cloud Secure Link page of the Admin Console, and configure at least one resource for that client. For steps, see Admin Console: Cloud Secure Link.

After registration, the Admin Console provides the following items, which you will need to save on the server you are using to install the client:

• Cluster join token: Temporary token valid for 8 hours. Used for initial registration and after configuration changes.
• Configuration file: Defines the connection and automatic update properties for your client.
• Validation file: Used to hash your configuration file. Prevents startup and connection if your client configurations do not match the configurations generated in the Admin Console.

Deploy the client

You can deploy the Cloud Secure Link client using Kubernetes (recommended) or standalone Docker.

Verify the client artifacts

Cloud Secure Link client container images and Helm charts are hosted in a public AWS Elastic Container Registry (ECR). Credentials are not required to access and pull artifacts from this registry.

Appian signs its artifacts so that you can confirm they are authentic and have not been tampered with before you deploy them. To verify these signatures, Appian recommends Cosign, an open-source tool for signing and verifying container images and other artifacts. Follow the Cosign installation instructions.

After installing Cosign, run the following command in a terminal to save the Appian Cloud Secure Link public image signing key:

1
2
3
4
5
6
cat <<EOF > /tmp/appian-cloud-secure-link-public-key.pem
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmihYeh+jEmNW43nWiSkR9sJhduGC
014cx4VWVRPlsxJOOMp+9aw36P9pOAKsuafhCxQHLj1zfsrgj/5mjVvCSQ==
-----END PUBLIC KEY-----
EOF

Then run the following to verify the artifact signatures, replacing <VERSION> with the version of the Cloud Secure Link client that you are deploying. If you are deploying with standalone Docker, run only the client-container command.

1
2
cosign verify --key /tmp/appian-cloud-secure-link-public-key.pem public.ecr.aws/appian-cloud-secure-link/client-chart:<VERSION>
cosign verify --key /tmp/appian-cloud-secure-link-public-key.pem public.ecr.aws/appian-cloud-secure-link/client-container:<VERSION>

Each command outputs a verification message. For example, the client-chart command produces the following structure:

1
2
3
4
5
6
7
8
9
10
$ cosign verify --key /tmp/appian-cloud-secure-link-public-key.pem public.ecr.aws/appian-cloud-secure-link/client-chart:1.0.1

Verification for public.ecr.aws/appian-cloud-secure-link/client-chart:1.0.1 --

The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"<REPOSITORY>"},"image":{"docker-manifest-digest":"sha256:<DIGEST>"},"type":"cosign container image signature"},"optional":{"Bundle":{ ... }}}]

Deploy the client in Kubernetes

Follow the steps in this section to install the Cloud Secure Link client in a Kubernetes cluster.

Prerequisites for deploying with Kubernetes

To deploy your Cloud Secure Link client with Kubernetes, ensure you have access to the following:

• A Kubernetes cluster that can reach Appian's public ECR
• A terminal with kubectl access to your cluster
• A terminal with the helm and docker CLI commands available

Install the client Helm chart

On a server with helm and kubectl access, and your downloaded configuration and validation files, run the following command to deploy the Helm chart for the Cloud Secure Link client:

1
2
3
4
5
6
helm install <HELM_DEPLOYMENT_NAME> oci://public.ecr.aws/appian-cloud-secure-link/client-chart:<VERSION> \
    --set image.uri="public.ecr.aws/appian-cloud-secure-link/client-container:<VERSION>" \
    --set-file cloudSecureLinkClientConfigs.clientConfiguration=<PATH_TO_CONFIG_FILE> \
    --set-file cloudSecureLinkClientConfigs.clientConfigurationValidationHash=<PATH_TO_VALIDATION_FILE> \
    --set-file cloudSecureLinkClientConfigs.clientJoinToken=<PATH_TO_TOKEN_FILE> \
    --namespace <YOUR_NAMESPACE>

In the command above:

• <HELM_DEPLOYMENT_NAME>: Name of your Helm chart release. Must be unique within your Kubernetes cluster.
• <VERSION>: Version of the Cloud Secure Link client Helm chart.
• <PATH_TO_CONFIG_FILE>: Path to the configuration file you downloaded in the Admin Console.
• <PATH_TO_VALIDATION_FILE>: Path to the validation file you downloaded in the Admin Console.
• <PATH_TO_TOKEN_FILE>: Path to the token file you created in the Admin Console.
• <YOUR_NAMESPACE>: The Kubernetes namespace in which your resources will be deployed.

If you need to configure network policies, allow egress access to the following domains on port 443:

• csl-<uuid>.appiancloud.com: The Cloud Secure Link cluster URL. Find the domain in your client configuration file.
• cdn.teleport.dev: Allow this domain access if you have auto-update enabled, so the container can download Teleport updates.

Check the deployment logs for startup

View the log for your client by running:

1
kubectl logs <HELM_DEPLOYMENT_NAME>-0

You should see a message similar to the following when your client has started successfully:

1
INFO [APP:SERVI] All applications successfully started. pid:1710.1 service/service.go:6265

Uninstall the Helm chart

To uninstall your Helm deployment, run the following command:

1
helm uninstall <HELM_DEPLOYMENT_NAME> --namespace <YOUR_NAMESPACE>

Deploy the client in standalone Docker

Follow the steps in this section to install the Cloud Secure Link client as a standalone Docker container.

Prerequisites for deploying with Docker Compose

To deploy your Cloud Secure Link client with Docker Compose, ensure you have access to the following:

• A Docker server that can reach Appian's public ECR and has the docker CLI commands available

Create a Docker Compose file

Use the following Docker Compose file as a template reference:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# docker-compose.yml

services:
  csl-client:
    image: public.ecr.aws/appian-cloud-secure-link/client-container:<VERSION>
    tty: true
    tmpfs:
      - /run
      - /run/lock
      - /tmp
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:rw
      - <PATH_TO_CONFIG_FILE>:/etc/csl_client_config.yaml:ro
      - <PATH_TO_VALIDATION_FILE>:/etc/hash.txt:ro
      - <PATH_TO_TOKEN_FILE>:/tmp/token:ro
      - teleport-data:/var/lib/teleport
    cgroup: host
    stop_signal: SIGRTMIN+3
  # networks:
  #  - csl-net

  # Replace with your real service or add more.
  # nginx:
  #   image: nginx:alpine
  #   ports:
  #     - "9000:80"
  #   networks:
  #     - csl-net

#networks:
#  csl-net:
#    driver: bridge

volumes:
  teleport-data:

In the template above:

• <VERSION>: Version of the Cloud Secure Link client container.
• <PATH_TO_CONFIG_FILE>: Path to the configuration file you downloaded in the Admin Console.
• <PATH_TO_VALIDATION_FILE>: Path to the validation file you downloaded in the Admin Console.
• <PATH_TO_TOKEN_FILE>: Path to the token file you created in the Admin Console.

Install the Docker container

In your terminal, run the following command to start your client container:

1
docker compose -f <PATH_TO_DOCKER_COMPOSE_FILE> up -d

Check the container logs for startup

View the log for your client by running:

1
docker compose logs csl-client

You should see a message similar to the following when your client has started successfully:

1
INFO [APP:SERVI] All applications successfully started. pid:1710.1 service/service.go:6265

Test your resource connection

Appian automatically routes requests to your self-hosted resource using the connection hostname for that resource in a connected system object and/or integration object, depending on the resource type. Once the client is running, no additional routing configuration is required.

To test the connection:

1. Open the connected system object associated with the resource.
2. Confirm that the URL configured for the resource contains the hostname of your self-hosted resource—for example, the Connection URL field in a data source connected system.
3. Run the appropriate test:
   • If the resource is a data source, click TEST CONNECTION in the connected system object.
   • If the resource is an API, open an integration object that uses the connected system, and click TEST REQUEST.

(Optional) Transition from VPN or AWS PrivateLink

If you are transitioning from VPN or AWS PrivateLink to Cloud Secure Link, see Transition to Cloud Secure Link.

(Optional) Deploy multiple replicas for high availability (HA)

Running multiple Cloud Secure Link client replicas provides automatic failover. Each replica establishes its own independent reverse tunnel to Appian. If one replica becomes unavailable, traffic automatically routes through the remaining replica.

Keep in mind what high availability for Cloud Secure Link does not provide:

• No deterministic load balancing. Appian's routing layer independently selects a preferred client replica from the available set. Traffic may flow through more than one replica at a time, but the distribution may change between sessions.
• No active-passive failover. All replicas can carry traffic simultaneously, not just a single standby replica waiting to take over.

As long as the environment where you want to deploy Cloud Secure Link in HA meets the requirements, you can deploy Cloud Secure Link in HA in either Kubernetes or standalone Docker.

Requirements

Each replica must have its own persistent storage for /var/lib/teleport. This directory stores your client's unique identity and certificates. If two replicas share this directory, they will conflict and fail to connect. Ensure that your replicas are mounted at separate locations on disk.

Before deploying your client in HA, ensure the following:

1. You have a working single-replica Cloud Secure Link client connected to your Appian environment.
2. You have validated end-to-end connectivity—your Appian application can reach the target services exposed through Cloud Secure Link.
3. Your infrastructure (Kubernetes cluster or Docker host) has sufficient capacity to run additional replicas.

Each new replica client requires a token to connect to Appian. Generate a new token in the Admin Console and ensure it is available in each replica's individual persistent storage. The same token can be used by multiple replicas. After initial authentication using the token, each replica will use unique, rotating certificates for ongoing authentication.

Kubernetes deployment

Appian's Helm chart deploys the Cloud Secure Link client as a StatefulSet. Each replica automatically receives its own persistent volume for /var/lib/teleport, so each new replica registers as an independent client with its own tunnel to your Appian site.

Scale to your desired replica count by running:

1
kubectl scale statefulset <HELM_DEPLOYMENT_NAME> --replicas=<NUMBER_OF_REPLICAS>

Docker deployment

Docker Compose does not automatically create per-replica volumes. You must define each replica as a separate service with its own named volume.

Use the following Docker Compose file as a template reference for configuring HA:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# docker-compose.yml

services:
  csl-client-1:
    image: public.ecr.aws/appian-cloud-secure-link/client-container:<VERSION>
    tty: true
    tmpfs:
      - /run
      - /run/lock
      - /tmp
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:rw
      - <PATH_TO_CONFIG_FILE>:/etc/csl_client_config.yaml:ro
      - <PATH_TO_VALIDATION_FILE>:/etc/hash.txt:ro
      - <PATH_TO_TOKEN_FILE>:/tmp/token:ro
      - teleport-data-1:/var/lib/teleport
    cgroup: host
    stop_signal: SIGRTMIN+3
  csl-client-2:
    image: public.ecr.aws/appian-cloud-secure-link/client-container:<VERSION>
    tty: true
    tmpfs:
      - /run
      - /run/lock
      - /tmp
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:rw
      - <PATH_TO_CONFIG_FILE>:/etc/csl_client_config.yaml:ro
      - <PATH_TO_VALIDATION_FILE>:/etc/hash.txt:ro
      - <PATH_TO_TOKEN_FILE>:/tmp/token:ro
      - teleport-data-2:/var/lib/teleport
    cgroup: host
    stop_signal: SIGRTMIN+3

volumes:
  teleport-data-1:
  teleport-data-2:

Recommended replica count

Adding replicas improves resilience but does not proportionally increase throughput. Traffic distribution across replicas is non-deterministic.

Verify the HA deployment

After scaling, confirm that each replica has registered as a separate agent with its own identity. Replicas that share a host UUID indicate a storage misconfiguration.

Verify in Kubernetes

1
2
kubectl exec <HELM_DEPLOYMENT_NAME>-0 -- cat /var/lib/teleport/host_uuid
kubectl exec <HELM_DEPLOYMENT_NAME>-1 -- cat /var/lib/teleport/host_uuid

Verify in Docker

1
2
docker compose exec csl-client-1 cat /var/lib/teleport/host_uuid
docker compose exec csl-client-2 cat /var/lib/teleport/host_uuid

Each replica should report a distinct host UUID. If two replicas show the same UUID, their /var/lib/teleport volumes are shared and must be separated.

(Optional) Configure connections for Enhanced Business Continuity

Cloud Secure Link is compatible with Enhanced Business Continuity. To pre-configure Cloud Secure Link connections in your secondary region, contact Appian Support.

Cloud Secure Link failover works as follows:

1. Appian configures Cloud Secure Link services in your backup Appian Cloud region using the same connection information as your primary region.
2. Appian provides you with a temporary token to authenticate with the backup Cloud Secure Link service.
3. You deploy a failover Cloud Secure Link client in a location of your choice, using the configuration files and token provided by Appian.
4. Your client connects to the failover Cloud Secure Link service.
5. During a failover event, your Appian Cloud site moves to the secondary region and forwards traffic to your backup Cloud Secure Link client.

In the event of a region-wide failure, connectivity resumes once the backup environment is restored and the pre-deployed client connects to the Secure Link Service in the backup region.

Feedback