Secure PostgreSQL provisioning with PDS

This topic outlines the procedure for provisioning PostgreSQL with Transport Security Layer (TSL) within a Kubernetes cluster using PDS. This approach ensures the isolation of management infrastructure deployed in separate namespaces. It enables the integration of PDS into your Kubernetes cluster for creating PostgreSQL instances.

To achieve this, Role-Based Access Control (RBAC) rules and roles are configured within each namespace to manage the permissions of a ServiceIdentity used by deployments in that namespace.

Prerequisites

• A configured and accessible Kubernetes cluster
• Ensure that PDS is integrated into your cluster's storage infrastructure.
• Generate Service API Keys for each user or service that will be involved in the PostgreSQL provisioning process.
• Configure RBAC within your Kubernetes cluster. Ensure RBAC rules and roles are defined to manage permissions and access control for ServiceIdentities within namespaces.
• Create the necessary Kubernetes namespaces where PostgreSQL instances will be provisioned.
• Prepare TLS certificates for securing the PostgreSQL database communication.
• Ensure the Service API Keys are stored in a manner that prevents unauthorized access.
• Ensure that users and services have access and permissions within PDS to deploy and manage PostgreSQL instances.

Use case

The integration of ServiceIdentity with namespaces in Portworx Data Services (PDS) unveils a powerful use case. Imagine a cloud-native platform that hosts multiple tenants, each running its own applications and services in a Kubernetes cluster managed by PDS that aims to ensure data isolation, security, and fine-grained access control for each tenant's data. Also, PDS is responsible for managing data storage and persistence in the Kubernetes cluster.

ServiceIdentity is a mechanism within PDS that assigns unique identities to different services and applications. Namespaces are used to logically segregate and organize resources within the Kubernetes cluster.

In multi-tenant applications, each tenant deploys its applications and services within a dedicated namespace on the Kubernetes cluster.

ServiceIdentity with namespace integration

Each tenant's application and service is assigned a unique ServiceIdentity within PDS. Additionally, namespaces are created for each tenant, ensuring a clear separation of resources. Data generated or utilized by a tenant's applications is stored within the respective namespace and associated with the tenant's ServiceIdentity. This strict data isolation prevents data leakage between tenants.

Access control policies are defined based on ServiceIdentity and namespace combinations. For example, Tenant A's ServiceIdentity may have read and write access to their own namespace but is denied access to resources in Tenant B's namespace. PDS can dynamically allocate storage resources based on the needs of each tenant. ServiceIdentities can be used to control resource consumption and scaling for each tenant independently.

Advantages of ServiceIdentity with namespace integration

• ServiceIdentity with namespaces ensures strict data separation, preventing unauthorized access and data leakage between tenants.
• Access control policies based on ServiceIdentity and namespace enhance security by limiting access to only authorized resources.
• Tenants can independently scale their resources without affecting other tenants.
• PDS complies with multi-tenancy regulations and data privacy standards by utilizing ServiceIdentity and namespaces for access control and data isolation.

In this use case, ServiceIdentity with namespaces in PDS empowers a multi-tenant cloud-native platform to offer secure, isolated, and scalable environments for various tenants, ensuring data privacy and regulatory compliance while maintaining efficient resource management.

Configure RBAC at namespace level

The RBAC configuration takes place at the namespace level in PDS, and the procedure involves the following steps:

1. Create a Service Identity: Use the ServiceIdentity API to create a service identity, which represents a specific application or service that requires controlled access.

2. Generate a JWT Token: Using the client ID and client token associated with the service identity, generate a JSON Web Token (JWT) token. This token will be used for authenticating the service identity.

3. Retrieve Namespace IDs: Before proceeding with access control, gather the namespace IDs for which you intend to manage user role assignments.

   To obtain the account ID required for this, you can use the list account API.

4. Create an IAM Rolebinding: Use the create IAM API to create a new IAM rolebinding. For example:

   

   The rolebinding JSON configuration should include:

   • actor_id: This label should specify the service identity's ID.
   • data.account: Define the permissions available for the account (for example, account-reader).
   • data.namespace: Specify access permissions for each namespace, including:
   • resource_ids: The IDs of the namespaces you wish to manage.
   • role_name: The name of the role assigned to the service identity for each namespace (for example, namespace-admin or namespace-reader). You can adjust this to control the level of access.

5. Authentication with Service Identity: Use the JWT token generated in step 2 for authenticating the service identity when making requests or accessing resources within the specified namespaces.

This RBAC configuration allows you to finely control access and permissions at the namespace level, enhancing security and ensuring that services and applications only have the necessary access within your PDS account.

Provision PostgreSQL using the PDS API

To provision PostgreSQL with TLS using the PDS API:

1. Generate a Service API key for each user:

   • Create a unique Service API Key for each user who intends to utilize PDS for PostgreSQL provisioning.
   • This API Key will serve as an authentication and authorization mechanism for users when interacting with PDS.

2. Implement RBAC Constraints on API Keys:

   • Implement RBAC constraints on the generated API Keys.
   • Configure RBAC policies to restrict the usage of each API Key to the specific Kubernetes namespace associated with each user.
   • RBAC ensures that users can only perform actions within their designated namespace.

3. Orchestrate PostgreSQL Deployment:

   • Utilize the generated API Keys to orchestrate the deployment of the PostgreSQL data service.
   • Specify the Kubernetes namespace as part of the deployment configuration to ensure the database is provisioned within the correct namespace.
   • All interactions with PDS related to PostgreSQL deployment should include the API Key associated with the user, ensuring accountability and proper access control.

4. Secure Storage of API Keys:

   • Store the generated API Keys securely within your infrastructure. Consider using a secure secrets management system or vault to safeguard these keys.
   • Limit access to the API Keys to authorized personnel only to prevent unauthorized use.

5. Onboard Kubernetes Clusters:

   • Onboard all the Kubernetes clusters belonging to users onto the PDS account that has been established for them.
   • Ensure that each Kubernetes cluster is properly configured to work with PDS and that the associated API Keys are accessible within the cluster for automation.

By following these steps, you establish a secure and controlled process for users to provision PostgreSQL databases with TLS support in your managed infrastructure using PDS. RBAC, API Key management, and secure storage practices are essential components of this process to maintain data integrity and security throughout the PostgreSQL deployment lifecycle.