Skip to main content

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 includes the network communication details required for PDS deployments, ensuring proper functionality in environments protected by firewalls, gateways, or other network protection appliances.

Key highlights:

  • All network connections are egress from the target cluster, with no open ingress ports required.
  • Network connections are encrypted (using TLS or SSH) and authenticated for secure communication.
  • Requests from the control plane to the target cluster are tunneled through an existing Teleport connection.
  • If using Portworx-managed DNS hosted on AWS (Default), specific configurations, including whitelisting, may be required for DNS resolution and endpoint syncing.

Network configuration details:

Target / ServiceDomainPortsProtocolsIPv4 AddressesAuthentication
PDS API servercloud.portworx.io443HTTPS, gRPC13.248.155.205
35.71.160.53		Bearer token
Teleport servercloud-teleport.portworx.io443HTTPS, SSH75.2.6.226
99.83.195.53		Join token, node certificate
Portworx-managed DNS for PDSus-east-1.console.aws.amazon.com443DNS, UDP/TCP3.3.8.1
3.3.9.1		Secret token
note
  • Static IP support: PDS provides static IP addresses to whitelist in your firewall rules. These IPs are listed in the table above for ease of access.
  • DNS resolution requirements: When using Portworx-managed DNS hosted on AWS, ensure the following:
    • Whitelist access to AWS Route53 services.
    • Allow outbound access to aws.amazon.com in the us-west region.
    • Whitelist the Global Accelerator endpoint (us-east-1.console.aws.amazon.com) for DNS traffic.

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.