Security data flows

Introduction

This document provides a security-focused overview of the Citrix SecurSpaces™ architecture and the main data flows between core components and external dependencies. It explains how user access, traffic handling, identity federation, workspace isolation, secrets management, and external integrations help protect sensitive development activity and maintain a secure operating model.

Data flow summary

Flow #	Component	Security data flow
1.	Developer endpoint	The developer endpoint represents the user’s device, such as a physical computer, thin client, or virtual desktop infrastructure (VDI) session. Users access SecurSpaces through a local IDE over SSH or through a web browser over HTTPS. Development activity runs remotely, helping prevent sensitive source code from being stored on the local endpoint.
2.	Network load balancer	The network load balancer provides Layer 4 connectivity between the public or enterprise network and the private SecurSpaces environment. It does not terminate TLS. Instead, it forwards raw TCP sessions and preserves end-to-end encryption until traffic reaches the ingress controller.
3.	Ingress controller or Gateway API	The Kubernetes ingress controller or Gateway API provides Layer 7 traffic routing for SecurSpaces services and acts as the TLS termination point for HTTPS traffic. By terminating TLS at this layer, it can inspect request metadata and apply routing rules that direct traffic to the appropriate internal SecurSpaces services. Downstream communication between the ingress layer and SecurSpaces internal services is encrypted with TLS. The permitted TLS versions and cipher suites for external traffic are set by the customer’s ingress configuration.
4.	Identity and access management	SecurSpaces can integrate with an enterprise identity provider (IdP) to support federated authentication through corporate single sign-on (SSO) using standards such as OpenID Connect (OIDC) or SAML. When this integration is used, user credentials remain managed by the customer’s identity system instead of being stored in SecurSpaces. SecurSpaces can also operate as the identity provider and manage user credentials directly.
5.	SecurSpaces control plane	The SecurSpaces control plane contains the core application logic and acts as the primary security and management hub. It performs SSH and TLS termination for traffic routing and proxying, which enables traffic inspection and detailed auditing of user sessions. It also provides the web administration UI and the SecurSpaces Core API, which hosts the platform’s primary business logic. For workspace management, the control plane sends orchestration requests to the Kubernetes control plane to manage the workspace lifecycle, including provisioning, scaling, and decommissioning. Workspace management operations follow a Kubernetes role-based access control (RBAC) model based on least privilege.
6.	SecurSpaces workspaces and storage	Workspaces are ephemeral, containerized environments isolated within the private network. Persistent data is stored on encrypted volumes so that source code and build caches remain secure and isolated if a workspace is restarted or destroyed.
7.	SecurSpaces proxy service	The SecurSpaces proxy service functions as a dedicated workspace egress firewall to help prevent data exfiltration. For what it does and why every connection passes through it, see How the SecurSpaces proxy service works. Outbound traffic from workspaces is routed through this component for URL filtering. This helps ensure that workspaces communicate only with approved external domains and helps prevent unauthorized data transfers to the internet.
8.	External dependencies	SecurSpaces relies on external components to manage application data, container images, code access, and security telemetry. Connectivity between SecurSpaces and these dependencies is managed by the customer using private network integration mechanisms such as private routing, VPN, network peering, or private endpoints. These controls help keep traffic within a secure and controlled network boundary.
9.	Kubernetes Secrets	SecurSpaces uses native Kubernetes Secrets to manage certificates, access keys, encryption keys, database credentials, and JSON Web Token (JWT) private keys. By default, these secrets are stored in `etcd`, which must be protected with encryption at rest. For environments with higher security requirements, SecurSpaces can integrate with advanced Kubernetes mechanisms such as the Secrets Store CSI Driver or External Secrets Operators.

Flow #

Component

Security data flow

Developer endpoint

The developer endpoint represents the user’s device, such as a physical computer, thin client, or virtual desktop infrastructure (VDI) session. Users access SecurSpaces through a local IDE over SSH or through a web browser over HTTPS. Development activity runs remotely, helping prevent sensitive source code from being stored on the local endpoint.

Network load balancer

The network load balancer provides Layer 4 connectivity between the public or enterprise network and the private SecurSpaces environment. It does not terminate TLS. Instead, it forwards raw TCP sessions and preserves end-to-end encryption until traffic reaches the ingress controller.

Ingress controller or Gateway API

The Kubernetes ingress controller or Gateway API provides Layer 7 traffic routing for SecurSpaces services and acts as the TLS termination point for HTTPS traffic. By terminating TLS at this layer, it can inspect request metadata and apply routing rules that direct traffic to the appropriate internal SecurSpaces services. Downstream communication between the ingress layer and SecurSpaces internal services is encrypted with TLS. The permitted TLS versions and cipher suites for external traffic are set by the customer’s ingress configuration.

Identity and access management

SecurSpaces can integrate with an enterprise identity provider (IdP) to support federated authentication through corporate single sign-on (SSO) using standards such as OpenID Connect (OIDC) or SAML. When this integration is used, user credentials remain managed by the customer’s identity system instead of being stored in SecurSpaces. SecurSpaces can also operate as the identity provider and manage user credentials directly.

SecurSpaces control plane

The SecurSpaces control plane contains the core application logic and acts as the primary security and management hub. It performs SSH and TLS termination for traffic routing and proxying, which enables traffic inspection and detailed auditing of user sessions. It also provides the web administration UI and the SecurSpaces Core API, which hosts the platform’s primary business logic. For workspace management, the control plane sends orchestration requests to the Kubernetes control plane to manage the workspace lifecycle, including provisioning, scaling, and decommissioning. Workspace management operations follow a Kubernetes role-based access control (RBAC) model based on least privilege.

SecurSpaces workspaces and storage

Workspaces are ephemeral, containerized environments isolated within the private network. Persistent data is stored on encrypted volumes so that source code and build caches remain secure and isolated if a workspace is restarted or destroyed.

SecurSpaces proxy service

The SecurSpaces proxy service functions as a dedicated workspace egress firewall to help prevent data exfiltration. For what it does and why every connection passes through it, see How the SecurSpaces proxy service works. Outbound traffic from workspaces is routed through this component for URL filtering. This helps ensure that workspaces communicate only with approved external domains and helps prevent unauthorized data transfers to the internet.

External dependencies

SecurSpaces relies on external components to manage application data, container images, code access, and security telemetry. Connectivity between SecurSpaces and these dependencies is managed by the customer using private network integration mechanisms such as private routing, VPN, network peering, or private endpoints. These controls help keep traffic within a secure and controlled network boundary.

Kubernetes Secrets

SecurSpaces uses native Kubernetes Secrets to manage certificates, access keys, encryption keys, database credentials, and JSON Web Token (JWT) private keys. By default, these secrets are stored in etcd, which must be protected with encryption at rest. For environments with higher security requirements, SecurSpaces can integrate with advanced Kubernetes mechanisms such as the Secrets Store CSI Driver or External Secrets Operators.

External dependency data flows

Dependency	Security data flow
MongoDB database	Stores application state. SecurSpaces uses AES-128-GCM to protect sensitive data at the application layer, including developer personal secrets.
Code repositories	Git repository integrations are routed through the SecurSpaces proxy service, enabling SSO and enforcing SecurSpaces security policies for Git repository access and management.
Container registry	Hosts the container images used by SecurSpaces workspaces. Images can be stored across one or more registries, depending on the customer environment. A container registry also provides images for core SecurSpaces components, such as the SecurSpaces control plane and SecurSpaces proxy service. These core component image flows are typically omitted from high-level data-flow diagrams because they are not configurable in SecurSpaces.
SIEM	Receives audit logs and security events from SecurSpaces for centralized monitoring, compliance, and alerting. Examples include SIEM platforms such as Splunk.

Dependency

Security data flow

MongoDB database

Stores application state. SecurSpaces uses AES-128-GCM to protect sensitive data at the application layer, including developer personal secrets.

Code repositories

Git repository integrations are routed through the SecurSpaces proxy service, enabling SSO and enforcing SecurSpaces security policies for Git repository access and management.

Container registry

Hosts the container images used by SecurSpaces workspaces. Images can be stored across one or more registries, depending on the customer environment. A container registry also provides images for core SecurSpaces components, such as the SecurSpaces control plane and SecurSpaces proxy service. These core component image flows are typically omitted from high-level data-flow diagrams because they are not configurable in SecurSpaces.

SIEM

Receives audit logs and security events from SecurSpaces for centralized monitoring, compliance, and alerting. Examples include SIEM platforms such as Splunk.

Kubernetes Secrets data flows

Secret type	Use
Certificates	TLS keys for the SecurSpaces control plane and internal components.
Access keys	SSH private keys for workspace authentication. Personal SSH identities use Ed25519.
Encryption keys	AES-128 keys used with AES-GCM for application-level data protection.
Database credentials	Passwords and connection credentials for MongoDB.
JWT private keys	Keys used for secure token signing.

Secret type

Use

Certificates

TLS keys for the SecurSpaces control plane and internal components.

Access keys

SSH private keys for workspace authentication. Personal SSH identities use Ed25519.

Encryption keys

AES-128 keys used with AES-GCM for application-level data protection.

Database credentials

Passwords and connection credentials for MongoDB.

JWT private keys

Keys used for secure token signing.

Security considerations

SecurSpaces uses a layered security model across the endpoint, network, application, workspace, and infrastructure layers. The customer remains responsible for the security of the hosting environment, including network boundaries, encryption at rest for infrastructure services, Kubernetes cluster hardening, and protection of etcd.

Where the deployment requires stronger secrets protection, customers can use Kubernetes-native integrations such as the Secrets Store CSI Driver or External Secrets Operators to connect SecurSpaces with an enterprise secrets management platform.

Introduction

Data flow summary

External dependency data flows

Kubernetes Secrets data flows

Ports and cryptography

Security considerations

In this article