DSM 9.0.1 – Using IaaS Resource Policies to fine-tune database deployments in VCF Automation
In this post, we will take a look at another new feature of VCF Automation, IaaS Resource Policies. I will demonstrate how these IaaS policies can be used with Data Service Policies and DSM provisioned databases to fine-tune certain parameters related to the database. You may have already seen the concept of Data Service Policies in previous posts. These are policies set at the Provider level which can dictate which database engines, which database versions and which backup locations a tenant of an organization can consume. However additional validations or constraints in an IaaS policy can be applied at an organization or a project level, allowing for even more fine grained controls over what settings a tenant can place on a database.
In the example that I will show you here, I am going to stipulate that certain members of an organization need to set their retention policy for backups to 91 days rather than 30 days, which is the default. Let’s begin by navigating to the VCF Automation Organization Portal, and selecting the Manage & Govern view. Here you will find the Policies section in the left-hand navigation bar. We are going to create an IaaS Resource Policy. Click on that.
This will open the ‘New Policy’ wizard. Provide a name an optional description, and which Organization or Project(s) that the policy applies to. You can even get more granular in the criteria section and include Namespace names, Namespace classes or Regions to associate with the policy.
If you click on the “+ Load Policy Template” button, you will see some examples of pre-defined IaaS Resource Polices, which you can use as a template for further policies. There are a number of out-of-the-box templates such as a policy that enforces a maximum of one control plane/worker node on a Kubernetes cluster. This is just an FYI, so once you have had a chance to look at some of the examples, you can cancel the load template view and we can proceed with our database-specific IaaS policy.
Begin by filling in the name, scope, etc:
Next, add the code block for the validation, with a goal of requiring the retention policy for backups to be set to 91 days rather than the default value of 30 days. To do that, the code looks to match on the PostgresClusters API type object, and then match on the spec.backupConfig.backupRetentionDays field and express a constraint. Prior knowledge of the PostgresCluster specification is necessary to determine where to place to the constraints.
The IaaS Resource Policy type provides a policy-as-code approach using Kubernetes Validation Admission Policy. Validating admission policies use the Common Expression Language (CEL) to declare the validation rules of a policy. In the code above, it is using the `has()` function to safely check the the fields exist before accessing them, and then validates that `backupRetentionDays == 91`. If it does not match 91, then we will generate a message to the user indicating that this field is not set correctly.
Here is the actual code block. It is essentially the spec section from a Kubernetes Validating Admission Policy.
failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["databases.dataservices.vmware.com"] apiVersions: ["v1alpha1"] operations: ["CREATE", "UPDATE"] resources: ["postgresclusters"] validations: - expression: "has(object.spec.backupConfig) && has(object.spec.backupConfig.backupRetentionDays) && object.spec.backupConfig.backupRetentionDays == 91" messageExpression: "'backupRetentionDays must be exactly 91, but got ' + string(object.spec.backupConfig.backupRetentionDays)" message: "backupRetentionDays must be exactly 91" reason: Invalid
Once created, the policy becomes visible in the “Definitions” view. If there are any issues with your policy definition, they will be highlighted here.
You can also see the scope of a policy, for example which Project and which Namespace it applies to.
And any time that this policy needs to do an enforcement on a database provisioning operation, this is visible in the Enforcements view:
With this in mind, let’s now try to provision a Postgres database with a retention policy set to the default value of 30 days from a tenant namespace in the project to which I have applied the policy. It should prevent me from doing so, and report the reason why … which it does.
The admission control policy prevented the deployment of a Postgres database due to the incorrect backup retention set by the user (30 days instead of 91). This is just one example of using the new IaaS Resource Policy engine for database resources.
If I try the exact same deployment, but this time specify a retention time of 91 days for backups, then the database deploys successfully as the condition in the IaaS Resource policy is met.
Here is another simple snippet of validation code, this time verifying that the name of the database is at least 8 characters long:
validations: - reason: Invalid message: databaseName must be greater than 8 chars expression: has(object.spec.databaseName) && size(object.spec.databaseName) > 8 messageExpression: "'IaaS Policy Validation issue: database name must be greater than 8 characters, but got ' + string(size(object.spec.databaseName))" failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: - databases.dataservices.vmware.com resources: - postgresclusters operations: - CREATE - UPDATE apiVersions: - v1alpha1
And now any attempt to create a database with a name that is less than 8 characters will be constrained by this policy:
Summary
Hopefully this post has highlighted the power of IaaS Resource Policies. Data Service Policies (DSP) used by DSM in VCF Automation do not cover all the fields of PostgresCluster API object. Also, DSPs are only available at the Provider level. IaaS Resource Policies are a great complement to DSPs. IaaS Resource Policies are available at the Organization/Tenant level and uses expressions that can put restrictions on any API object and on any field.
As seen in the above examples, we are able to restrict the backup retention and the database name length in a PostgresDatabase object. DSPs do not control this today. But using an IaaS Resource Policy, it is possible to say that you want to match on the PostgresCluster API type, and then you can match on the spec.databaseName or spec.backupConfig.backupRetentionDays field and express an appropriate constraint. Indeed, you can match of any of the fields and create any validation or constraint that you wish. This is a very powerful VCF and VCF Automation feature.
