Security concepts

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 Portworx agent manifest to initiate connection from the target cluster to the control plane, and then install the PDS operator. 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 Portworx agent and the PDS operator 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

The deployment process begins with installing the Portworx agent, which sets up the foundation for storage management within the cluster. Following this, the Portworx agent facilitates the deployment of the PDS Operator and its allied components. This two-step process ensures a robust and manageable setup for running and managing data services within a Kubernetes cluster, leveraging the capabilities of both Portworx agent and PDS Operator.

• Teleport agent to create a secure proxy for Kubernetes API access.
• 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-plane and pds-control-plane-portworx-api cluster roles
• pds-control-plane and pds-control-plane-portworx-api cluster role bindings

The benefits of this approach are:

• No open ingress ports are required in the target cluster.
• Only open egress port 443 is 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:

1. Asks the Teleport API server to provide short-time credentials for a specific target cluster.
2. Connects through the Teleport Kubernetes proxy to the Kubernetes API server of the target cluster.
3. Calls the Portworx Service API to store the cloud credentials.

note

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:

1. PDS API worker asks Teleport API Server to provide short-time credentials for a particular target cluster.
2. PDS API worker connects through the Teleport Kubernetes proxy to the Kubernetes API server of the target cluster.
3. PDS API worker creates or updates a custom resource according to the data service type. For example, Cassandra, PostgreSQL, and so on.
4. PDS deployments operator reconciles the service custom resource by creating or updating a corresponding Database CR.
5. 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:

1. PDS API worker asks Teleport API Server to provide short-time credentials for a particular target cluster.
2. PDS API worker connects through the Teleport Kubernetes proxy to the Kubernetes API server of the target cluster.
3. PDS API worker creates a Backup CR.
4. PDS Backups Operator reconciles the Backup CR by creating a Job to execute a backup script of a particular data service.
5. When the backup script finishes, PDS Backups Operator creates a volume snapshot of type cloudsnap.
6. 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:

1. PDS API worker asks Teleport API Server to provide short-time credentials for a particular target cluster.
2. PDS API worker connects through the Teleport Kubernetes proxy to the Kubernetes API server of the target cluster.
3. PDS API worker creates a Backup CR.
4. PDS Backups Operator reconciles the Backup CR by creating a CronJob resource to create Jobs resources according to the schedule.
5. When a Job is created, it executes a backup script of a particular data service.
6. When the backup script finishes, PDS Backups Operator creates a volume snapshot of type cloudsnap.
7. Stork uploads the snapshot to a corresponding backup target.

Portworx Security and PDS integration

If your Kubernetes cluster is running Portworx Enterprise with Security (PX-Security) enabled, PDS will automatically detect it, which you can view in the Cluster information. When PDS deployments are made on such security-enabled clusters, data services will ensure secure and encrypted communication to the storage.

To configure PX-Security, follow the instructions in Portworx documentation.

note

If Portworx Security is enabled after PDS is already installed, it may take up to five minutes for PDS to automatically detect the security changes and fully integrate with the new security settings.

Limitations

• Disabling Portworx Security on a Kubernetes cluster running Portworx Enterprise with active PDS deployments can cause data service deployments and storage pools to become unresponsive. As a workaround, create new backup locations, schedules, or cloud credentials, then restore the deployments to clusters with the appropriate Portworx Security settings to maintain PDS deployment continuity.
• When Portworx Security is enabled with guest access initially allowed, PVC operations (such as creating or resizing volumes) on existing storage classes will fail once guest access is disabled, even after recreating the storage classes. However, new storage classes created after disabling guest access will function properly. To avoid issues, if PDS is installed before enabling Portworx Security, always enable Portworx Security with guest access set to Disabled from the start.

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	cloud.portworx.io	443	HTTPS, gRPC	Bearer token
  Teleport server	cloud-teleport.portworx.io	443	HTTPS, SSH	Join token, node certificate

Network communication for SaaS deployments

If you run your Kubernetes clusters behind network protection appliances (such as firewalls, IDPs, or gateways), specific network configurations are required to ensure proper communication for PDS deployments, especially when using Portworx-managed DNS with SaaS.

If your environment uses Default, a Portworx-managed DNS hosted on Amazon Web Services (AWS) and built as a private DNS offering using AWS Route53:

• Whitelist access to AWS Route53 services for DNS resolution.

• Ensure that aws.amazon.com is allowed for outbound access in the us-west region.

• To enable endpoint syncing, whitelist the following Global Accelerator endpoint for DNS traffic:

  • Endpoint: us-east-1.console.aws.amazon.com
  • IP addresses: 3.3.8.1, 3.3.9.1
  • Port: 443

Failure to allow these endpoints may result in DNS resolution or endpoint syncing issues for PDS deployments.

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	Two static IPv4 addresses	13.248.155.205 35.71.160.53	cloud.portworx.io	https/443
Teleport	Two static IPv4 addresses	75.2.6.226 99.83.195.53	cloud-teleport.portworx.io	https/443

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 supports both HTTP CONNECT proxies and MITM proxies, such as Zscaler. See here for a step-by-step guide on configuring PDS with proxy support.

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.

📄️ Database users

Know the users / tokens and the corresponding permissions for each user created by PDS

📄️ RBAC

The PDS platform implements a hierarchical role-based access control (RBAC) system: