Security Data Flow

Introduction

This document provides a security-focused overview of the Citrix Secure Developer Spaces (SDS) 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 SDS 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 SDS 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 SDS 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 SDS services. To support a zero-trust architecture, downstream communication between the ingress layer and SDS internal services is secured with mutual TLS (mTLS).
4.	Identity and access management	SDS 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 SDS. SDS can also operate as the identity provider and manage user credentials directly.
5.	SDS control plane	The SDS 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 SDS 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.	SDS 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.	SDS proxy	The SDS proxy functions as a dedicated workspace egress firewall to help prevent data exfiltration. 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	SDS relies on external components to manage application data, container images, code access, and security telemetry. Connectivity between SDS 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	SDS 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, SDS 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 SDS 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 SDS 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 SDS 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 SDS services. To support a zero-trust architecture, downstream communication between the ingress layer and SDS internal services is secured with mutual TLS (mTLS).

Identity and access management

SDS 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 SDS. SDS can also operate as the identity provider and manage user credentials directly.

SDS control plane

The SDS 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 SDS 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.

SDS 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.

SDS proxy

The SDS proxy functions as a dedicated workspace egress firewall to help prevent data exfiltration. 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

SDS relies on external components to manage application data, container images, code access, and security telemetry. Connectivity between SDS 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

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

Dependency

Security data flow

MongoDB database

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

Code repositories

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

Container registry

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

SIEM

Receives audit logs and security events from SDS 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 SDS control plane and internal components.
Access keys	SSH private keys for workspace authentication.
Encryption keys	AES-128 symmetric keys 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 SDS control plane and internal components.

Access keys

SSH private keys for workspace authentication.

Encryption keys

AES-128 symmetric keys for application-level data protection.

Database credentials

Passwords and connection credentials for MongoDB.

JWT private keys

Keys used for secure token signing.

Security considerations

SDS 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 SDS with an enterprise secrets management platform.

Introduction

Data flow summary

External dependency data flows

Kubernetes Secrets data flows

Security considerations

In this article