Citrix SecurSpaces™

SDS CLI reference

sds-cli installs, upgrades, and manages Citrix SecurSpaces™ deployments. It runs inside the Strong Installer container.

This page describes the commands and their flags. For the procedures that use them, see Install with the Strong Installer CLI and Upgrade.

Note:

This command was previously named strong-cli. The binary is now sds-cli. A strong-cli symbolic link remains in the container, so existing scripts continue to work, but use sds-cli in new work.

Run the CLI

The Strong Installer is published on Docker Hub. The image tag matches the SecurSpaces release you are installing or upgrading to.

docker run -it --rm -v ${PWD}:/strong-network/shared \
    strongnetwork/strong_installer:<version>
<!--NeedCopy-->

${PWD} is mounted to /strong-network/shared inside the container. The CLI writes configuration files and Helm charts to that location, so they remain on the host after the container exits.

To run a command without an interactive shell — for example in a pipeline — pass it as an argument:

docker run -it --rm -v ${PWD}:/strong-network/shared \
    strongnetwork/strong_installer:<version> \
    <command> [flags]
<!--NeedCopy-->

Commands

Command Purpose
install Install the platform for the first time.
upgrade Upgrade the platform to a new version.
push-images Push SecurSpaces images to a registry.
create-config Create the initial configuration file.
update-config Generate an updated configuration file from an existing one.
fetch-access-token Fetch a SecurSpaces access token.
fetch-helm-chart Fetch the Helm chart for a given configuration.
helm-upgrade Run helm upgrade against an existing deployment.
get-terraform Download the SecurSpaces Terraform provider.
deploy-demo Deploy a demo environment to a cloud or local environment.
stress-test Create workspaces for stress testing.

install and upgrade are the two commands used in a normal deployment. The others are building blocks that those two call, and are useful when you need to run a single stage on its own — for example, to push images from a machine that has registry access and then upgrade from elsewhere.

Common flag groups

Most commands compose the same groups of flags. This section describes each group once; the entry for each command lists the groups that apply to it.

Configuration file

Flag Description
-c, --config-file Last deployed configuration file, which must be in the directory you started the container from, for example config_2024.2.0.yaml
--ignore-config Do not read a configuration file

When you use --ignore-config, the CLI prompts for the values it would otherwise read from the file, such as the host domain and the registry URL.

Access token

Flag Description
-a, --access-token SecurSpaces access token
--gcp-key-file-path Path to the SecurSpaces service account key file, used to fetch a token
-d, --domain Domain override used when fetching the token

If you do not pass --access-token, the CLI fetches one using the other two flags or prompts for what it needs.

Source registry

The source registry is the Citrix registry that images are pulled from.

Flag Description
--source-registry-region Region to pull images from: US, EU, or Asia. Not case sensitive.
--source-registry-url Source registry URL, overriding the region

Destination registry authentication

The destination registry is your own registry, that images are pushed to. The CLI detects the registry type from its URL and prompts for the matching credentials. Use these flags to supply credentials non-interactively, for example in a pipeline that cannot answer prompts.

Flag Registry Description
--service-account-file-path Google Path to the Google Cloud service account key file
--access-key-id AWS Access key ID
--secret-access-key AWS Secret access key
--session-token AWS Session token
--service-principal-app-id Azure Service principal application ID
--service-principal-secret Azure Service principal client secret
--service-principal-tenant-id Azure Service principal tenant ID
--use-docker-login Any Authenticate with --registry-username and --registry-password instead of using cloud provider authentication
--registry-username Any Registry user name
--registry-password Any Registry password

Note:

--gcp-key-file-path and --service-account-file-path are different flags. The first authenticates against the Citrix source registry; the second authenticates against your destination registry.

Image selection

Flag Description
-w, --workspace-image-tag Workspace image tag
--bitnami-mongo-image-tag Bitnami MongoDB image tag
--skip-service-images Do not push service images
--skip-workspace-images Do not push workspace images
--skip-bitnamo-mongodb-image Do not push the Bitnami MongoDB image
--ignore-image Image to skip. Repeat the flag to skip several images.

Important:

--skip-bitnamo-mongodb-image is spelled as shown, with bitnamo. This is a known misspelling in the product. --skip-bitnami-mongodb-image is not recognized.

Cluster access

These flags tell the CLI how to reach your cluster when it runs kubectl and helm.

Flag Description
--ignore-kubectl-setup Skip kubectl setup for cloud authentication
--cluster-name Cluster name to use for the Helm upgrade
--azure-subscription-id Azure subscription ID
--azure-resource-group Azure resource group
--gcp-project-id Google Cloud project ID
--gcp-region Google Cloud region
--gcp-zone Google Cloud zone
--aws-region AWS region
--aws-resource-group AWS resource group

Proxy

Flag Description
--proxy HTTP or HTTPS proxy
--proxy-https HTTPS proxy
--proxy-http HTTP proxy
--no-proxy Hosts that bypass the proxy

Output and transport

Flag Description
--verbose Enable verbose output
--insecure Disable TLS certificate verification
--no-grpc Use REST instead of gRPC

install

Installs the platform for the first time. The command prompts for the initial configuration values, for registry authentication, and for the destination registry URL.

sds-cli install [flags]
<!--NeedCopy-->
Flag Description Default
-v, --version Platform version to install Value from the VERSION file in the container

Also accepts: configuration file, access token, source registry, destination registry authentication, image selection, cluster access, proxy, and output and transport flags.

Important:

After authentication, the Helm chart file is written to the shared directory. It contains your deployment configuration and should be secured immediately.

upgrade

Upgrades an existing deployment to a new version.

sds-cli upgrade -c <config-file> [flags]
<!--NeedCopy-->
Flag Description Default
-v, --version Platform version to upgrade to Value from the VERSION file in the container

Also accepts: configuration file, access token, source registry, destination registry authentication, image selection, cluster access, and output and transport flags. upgrade does not accept --insecure.

Upgrading without a configuration file

If the configuration file from the previous deployment is unavailable, pass --ignore-config. The CLI then prompts for each value it would have read from the file, including the host domain and the registry URL, and does not write a new configuration file.

Warning:

Without a configuration file you must supply every deployment parameter manually. Use this option only when the configuration file cannot be recovered.

push-images

Pushes SecurSpaces images to your registry without installing or upgrading.

sds-cli push-images [flags]
<!--NeedCopy-->

Accepts: configuration file, access token, source registry, destination registry authentication, image selection, and output and transport flags.

Tip:

--use-docker-login with --registry-username and --registry-password suppresses the authentication prompts entirely, which is what a non-interactive pipeline needs.

create-config

Creates the initial configuration file.

sds-cli create-config [flags]
<!--NeedCopy-->

Accepts: access token, source registry, proxy, and output and transport flags.

update-config

Generates an updated configuration file from an existing one.

sds-cli update-config -c <config-file> [flags]
<!--NeedCopy-->
Flag Description
-v, --version Platform version tag to write into the new configuration file

Also accepts: configuration file, access token, source registry, and output and transport flags.

fetch-access-token

Fetches a SecurSpaces access token and prints it.

sds-cli fetch-access-token [flags]
<!--NeedCopy-->

Accepts: configuration file, access token, and output and transport flags.

fetch-helm-chart

Fetches the SecurSpaces Helm chart for the configuration you supply.

sds-cli fetch-helm-chart -c <config-file> [flags]
<!--NeedCopy-->

Accepts: configuration file, access token, source registry, and output and transport flags.

helm-upgrade

Runs helm upgrade against an existing deployment, using a Helm chart you already fetched.

sds-cli helm-upgrade -c <config-file> --helm-chart-file-name <chart> [flags]
<!--NeedCopy-->
Flag Description
-c, --config-file Last deployed configuration file
--helm-chart-file-name Helm chart file to use for the upgrade
--verbose Enable verbose output

Also accepts the cluster access flags.

get-terraform

Downloads the SecurSpaces Terraform provider into the shared directory. Despite the command name, this does not fetch the Terraform binary itself — install Terraform separately.

For what the provider manages and how to configure it, see Terraform provider.

sds-cli get-terraform [flags]
<!--NeedCopy-->
Flag Description Default
-c, --config-file-name Last deployed configuration file  
-v, --version Provider version to fetch Latest version
-d, --domain Host domain  
--src-reg-key-file Path to the SecurSpaces service account key file  

Also accepts the output and transport flags.

Note:

This command uses --config-file-name, not the --config-file used by the other commands. The -c shorthand is the same.

deploy-demo

Deploys a demonstration environment. Use this for evaluation, not for production.

sds-cli deploy-demo [flags]
<!--NeedCopy-->
Flag Description Default
--deployment-location Where to deploy: cloud or local cloud
--helm-chart-version-tag Version of the Helm chart archive to download  
--helm-chart-registry Registry to pull the Helm chart from  
--skip-version-check Do not check that the version tag exists in the registry false
-v, --version Platform version tag  

Also accepts: configuration file, access token, source registry, proxy, and output and transport flags.

stress-test

Creates workspaces to load test a deployment. This is a testing tool, not part of installing or operating a production deployment.

sds-cli stress-test --domain <domain> --test-name <name> --workspaces <n> [flags]
<!--NeedCopy-->

--domain and --test-name are required for the command and all its subcommands. --workspaces is required for stress-test itself.

Flag Description Default
--domain Host domain. Required.  
--api-key Platform API key. Can also be set with the STRONG_API_KEY environment variable.  
--test-name Base name identifying the test, organization, project, and workspaces. Required. stress-test
--concurrency Maximum number of concurrent workspace requests  
--delay Seconds between sequential create requests when --concurrency is 1 0
--heartbeat-interval Send a heartbeat every N seconds from inside the workspace after startup. 0 disables it. 0
--workspaces Number of workspaces to create. Required. 0
--image-name Workspace image to use  
--region Region to create workspaces in Default region
--per-region Create workspaces in all available regions false
--no-cleanup Do not clean up resources when the test finishes or is interrupted false
--memory Memory in MB for each workspace  
--vcpu vCPU in MHz for each workspace  
--disk Disk size in GB for each workspace  
--gpu Number of GPUs for each workspace  
--state-on-create Initial workspace state: CREATE_AS_RUNNING or CREATE_AS_PAUSED  
--users Number of users to create and assign workspaces across 0
--user-email-prefix Email prefix for stress test users Value of --test-name
--user-role Project role assigned to created users developer

stress-test subcommands

Subcommand Purpose
cleanup Clean up resources created by a stress test
create-users Create users and add them to a new stress test project, without creating workspaces
delete-users Delete persisted stress test users, without deleting workspaces, project, or organization
pause Pause all workspaces in a project
resume Resume all workspaces in a project
pause-resume Pause and then resume all workspaces in a project