VMware SQL with Postgres for Kubernetes (VMware SQL with Postgres) is a relational database-as-a-service that automates the installation, management, monitoring, and updating of containerized Postgres instances running on-premises or in any cloud. In the past few VMware SQL with Postgres releases, the focus was on improving the availability and recoverability of the managed instances. Version 1.9 is highlighted by two features that enhance the manageability of Postgres instances and the deployment flexibility of the VMware SQL with Postgres product. Let’s take a closer look at these two new features.
Throughout the progression of 1.x product releases, VMware SQL with Postgres has added support for several popular Kubernetes management platforms. Version 1.9 continues this trend by enabling the deployment of VMware Postgres instances on RedHat OpenShift clusters.
RedHat OpenShift is an open-source, enterprise-grade Kubernetes platform for building, deploying, and managing containerized applications across on-premise, private cloud, and public cloud infrastructures. It is one of the leading container management platforms in the industry. Although Kubernetes is at the core of the platform, OpenShift incorporates additional features and policies that require specific settings to ensure a successful deployment of Tanzu Postgres. These settings are summarized below:
Installing the Postgres Operator
When preparing to install the VMware SQL with Postgres Operator on RedHat OpenShift, please review the Installing a Postgres Operator section of the product documentation to ensure all of the prerequisites are in place. With the prerequisites verified, the installation of the VMware SQL with Postgres Operator requires a customization of a parameter in the operator configuration file (values.yaml). This process is summarized as follows:
- Navigate to the location where the VMware SQL with Postgres distribution was downloaded and unpacked
- View the defaults of the file operator/values.yaml
- Located at the bottom of the file should be the key value used to enable OpenShift support
- Create a configuration override file in the same location as the values.yaml file. Name the file according to your preference
- Add the custom value to the override file to enable OpenShift support
echo "enableSecurityContext: false" >> ./operator/values-overrides.yaml
- To install the VMware SQL with Postgres Operator on OpenShift, specify the path to the value overrides file at the time of deployment
helm install <OPERATOR_NAME> <PATH_TO_CHART> --values=<PATH_TO_OVERRIDES_FILE> . . .
Deploying a Postgres Instance
With the VMware SQL with Postgres Operator installed, you can now proceed to deploy Postgres instances on OpenShift clusters. Be sure to review the Deploying a New Postgres Instance section of the product documentation and verify that all prerequisites are satisfied. The documentation provides step-by-step guidance on deploying a Postgres instance. These instances cannot run on the "default" namespace, so you must provide a target namespace for deployment. This can be done using the following command:
kubectl config set-context --current -namespace=<POSTGRES-NAMESPACE>
Follow the remaining steps outlined in the documentation to finish the deployment of a Postgres instance on OpenShift.
New User Roles
In Postgres you can create USERS and ROLES with granular access permissions. Each new USER and ROLE would need to be granted specific permissions for each database object. However, it is a recommended practice to create multiple roles with specific permissions, and assign your users to the appropriate roles.
Prior to VMware SQL with Postgres 1.9, the creation of a Postgres instance would automatically create two users that are assigned to two distinct roles with the following permissions:
- Admin User: (Read/Write) to all databases in the instance
- Application User: (DDL: Create, Drop, Alter, Truncate, Comment, Rename) + (DML: Select, Insert, Update, Delete)
Providing database access post-deployment could prove to be quite an administrative burden. Consider the scenario where you need to provide read-only access to 100 contractors and read-write access to 200 developers. Since the existing roles have associated permissions that are far greater than this requirement, someone with admin-level privileges would need to do one of the following:
- Grant each of the individual users with specific, fine-grained access to the database (YIKES!)
- Create a small number of roles with fine-grained access and assign the users to the appropriate role (Could be worse!)
To minimize the effort of providing user access to managed instances, VMware SQL with Postgres 1.9 introduces two new roles: readWriteUser and readOnlyUser. When creating a Postgres instance, two additional users (Read-Write and Read-Only) are created and assigned to the corresponding new role. You can customize the database name and user account names by setting the values in the manifest file. If custom names are not provided, the names will be set as follows:
- dbname: same name as the instance
- username: pgadmin
- appUser: pgappuser
- readWriteUser: pgrouser
- readOnlyUser: pgrwuser
Once the Postgres instance is deployed, now consider the same scenario with 100 contractors and 200 developers. With the readWriteUser and readOnlyUser roles already established, you simply assign the users to the appropriate role (Ahhhh, much better!).
In the future when additional users need read-only or read-write access, you simply take your users and assign them to a predefined role to provide the required database privileges.
RedHat Openshift support is now available as of VMware SQL with Postgres 1.9. This enables another major Kubernetes-based platform for VMware Postgres deployments. Likewise, the addition of new user roles makes it easier to manage user access to specific VMware SQL with Postgres managed instances. Use the links below to find out more about the new features or for additional details on VMware SQL with Postgres.