Security concepts
Portworx Data Services (PDS) uses a shared responsibility model for security. This means that Portworx secures certain components, but you must ensure the security of other components:
-
Portworx secures the SaaS portion of PDS known as the control plane.
-
You must secure components in the data plane.
Secure the data plane
You’re responsible for securing the following components in the data plane:
-
Target clusters: You provide the Kubernetes target clusters and are responsible for keeping them secure and up to date.
-
Backup targets: You provide the object stores used as backup targets and are responsible for keeping them secure.
-
Data service deployments: Portworx deploys certain components onto your target cluster, but ensures the integrity of these components when they’re deployed. Specifically, Portworx deploys the following:
-
Docker images
-
Operators and agents Portworx that manage your applications
-
Control access to data services
When PDS deploys a data service to your cluster, it creates an initial set of credentials. You are responsible for managing access to the data service from this point, including adding more users.
Connections
You can install the PDS Helm chart to initiate connection from the target cluster to the control plane. PDS agent connects to the PDS API server, Teleport agent connects to the Teleport API server. Teleport creates a reverse tunnel to facilitate proxy connections from the PDS control plane to the Kubernetes API server of a target cluster.
You can terminate connections by deleting the PDS agent and Teleport agent deployments.
Operations
This section explains how PDS manages the target cluster, backup, and data service deployment operations.
Target Cluster Management
The target cluster management is done in PDS by a secure reverse tunnel and Kubernetes proxy.
Target cluster auto-configuration
When you install PDS Helm chart, the PDS agent starts, registers the cluster at PDS API server, retrieves configuration details and reconfigures the following third-party components:
-
Teleport agent to create a secure proxy for Kubernetes API access.
-
Prometheus to push metrics to the PDS control plane.
-
External DNS to provide DNS endpoint for data service deployments through the AWS Route 53.
Access to Kubernetes API
When the Teleport agent is configured by the PDS agent, it creates an encrypted reverse tunnel from the target cluster to the PDS control plane. This tunnel acts as Kubernetes API proxy to provide the PDS control plane with access to the Kubernetes API server in the target cluster.
The PDS control plane is authenticated as the teleport:pds-system Kubernetes group with rights according to Role Based Access Control (RBAC) installed by PDS Helm chart:
-
pds-control-planeandpds-control-plane-portworx-apicluster roles -
pds-control-planeandpds-control-plane-portworx-apicluster role bindings
The benefits of this approach are:
-
No open ingress ports are required in the target cluster.
-
Only open egress ports 443 and 3024 are required in the target cluster.
-
Self-registration and auto-configuration of the target cluster.
Backup target set-up
This action is initiated when you add a new backup target or deployment target to PDS. The PDS control plane synchronizes backup target credentials, which are needed for cloud backups of data services. The PDS API worker:
-
Asks the Teleport API server to provide short-time credentials for a specific target cluster.
-
Connects through the Teleport Kubernetes proxy to the Kubernetes API server of the target cluster.
-
Calls the Portworx Service API to store the cloud credentials.
The cloud credentials in the PDS control plane are encrypted at rest.
Data service deployment
This occurs when you create or update a data service deployment using the PDS UI or API:
-
PDS API worker asks Teleport API Server to provide short-time credentials for a particular target cluster.
-
PDS API worker connects through the Teleport Kubernetes proxy to the Kubernetes API server of the target cluster.
-
PDS API worker creates or updates a custom resource according to the data service type. For example, Cassandra, PostgreSQL, and so on.
-
PDS deployments operator reconciles the service custom resource by creating or updating a corresponding Database CR.
-
PDS deployments operator reconciles the database CR by creating native Kubernetes resources such as StatefulSet, Service, Role, Rolebinding, and so on.
Ad-hoc data service backup
This action is initiated when you trigger an ad-hoc backup in the PDS UI:
-
PDS API worker asks Teleport API Server to provide short-time credentials for a particular target cluster.
-
PDS API worker connects through the Teleport Kubernetes proxy to the Kubernetes API server of the target cluster.
-
PDS API worker creates a Backup CR.
-
PDS Backups Operator reconciles the Backup CR by creating a Job to execute a backup script of a particular data service.
-
When the backup script finishes, PDS Backups Operator creates a volume snapshot of type cloudsnap.
-
Stork uploads the snapshot to a corresponding backup target.
Scheduled data service backup
This action is initiated when you add or change a backup policy to data service deployment in the PDS UI:
-
PDS API worker asks Teleport API Server to provide short-time credentials for a particular target cluster.
-
PDS API worker connects through the Teleport Kubernetes proxy to the Kubernetes API server of the target cluster.
-
PDS API worker creates a Backup CR.
-
PDS Backups Operator reconciles the Backup CR by creating a CronJob resource to create Jobs resources according to the schedule.
-
When a Job is created, it executes a backup script of a particular data service.
-
When the backup script finishes, PDS Backups Operator creates a volume snapshot of type cloudsnap.
-
Stork uploads the snapshot to a corresponding backup target.
Network communication
This section describes network communication between target cluster and control plane.
-
All network connections are egress from the target cluster. Therefore, no open ingress ports are required.
-
All network connections are encrypted (TLS or SSH) and authenticated.
-
Requests from the control plane to the target cluster don’t establish their own connections but are tunneled through an existing Teleport connection.
Target
Domain
Ports
Protocols
Authentication
PDS API server
prod.pds.portworx.com443
HTTPS
Bearer token
Cortex
prod-observability.pds.portworx.com443
HTTPS
Bearer token
Teleport server
prod-teleport.pds.portworx.com443, 3024
HTTPS, gRPC, SSH
Join token, node certificate
Static IP addresses support
A static IP address is a permanent Internet Protocol (IP) address assigned to a computer or other device. Unlike a dynamic IP address, which is assigned by a network provider and can change from time to time, a static IP address remains constant and does not change. This can be useful for devices that need to be accessed remotely, such as servers, or for applications that require a constant IP address for proper functionality. Having a static IP address also makes it easier to set up port forwarding rules, which are used to route incoming traffic to specific devices on a local network.
PDS provides the following static IPs that you can whitelist in your firewall rules:
Ingress | Loadbalancer | IPV4 addresses | DNS name | Ports |
PDS API server | Three static IPv4 addresses |
| prod.pds.portworx.com |
|
Observability | Three static IPv4 addresses |
| prod-observability.pds.portworx.com |
|
Teleport | Three static IPv4 addresses |
| prod-teleport.pds.portworx.com/ |
|
Security configurations
The PDS agent and Teleport agent are the two paths for accessing PDS services. Both require authentication, encrypt communications, and are continuously monitored to detect suspicious events.
Access through proxy servers
PDS, currently, does not support access through proxy servers.
Encryption
All communication between a target cluster and the control plane is encrypted in transit. Sensitive data stored in the PDS control plane. For example, backup target credentials such as Amazon S3, Azure, and GCP are encrypted at rest in the PDS database.