Enforce policies before updating

[worawatwi]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Is it possible to have policies validation before updating? Currently we used Pulumi CLI policy-pack and policy-pack-config to enforce policies in our CI before preview and update. It would be great if operator can check for policy violation and raise error.

Affected area/feature

Pulumi Kubernetes operator

[viveklak]

Thanks for opening the issue. Assigned to @squaremo for consideration/prioritization.

[squaremo]

This makes sense as a feature of the operator -- thanks for suggesting it @worawatwi.

[EronWright]

Thinking about possible designs, a key question would be how to attach policies to stacks, i.e. to form a policy group. Since policies are normally enforced by an administrator, it would make sense here to apply policies at the level of a Kubernetes namespace. Would the system also apply policies that were assigned in Pulumi Cloud via policy groups? That would imply that the stack's choice of backend would affect the applied policies.

Also consider how to support configurable policies (e.g. enforcement level, the allowed instance types, cost allowances, etc.). Perhaps the well-known config format would simply be pasted as a string, as opposed to devising a CRD-friendly variation.

Another aspect is how/where to source the policy packs. Would the system draw from the published policy packs? From volumes or images? Ideally any such image or volume would be automatically attached to the workspace pod without any per-Stack configuration.

One idea would be to introduce a new custom resource type, that an administrator may use to attach policies to the stacks within a given namespace.

apiVersion: pulumi.com/v1alpha1
kind: PolicyGroup
metadata:
  namespace: my-namespace
policyPacks:
- name: <org-name/<policy-pack-name>
  version: 0.0.1
  config: |
    {
      "all": {
        "enforcementLevel": "disabled"
      },
      "a-policy": {
        "enforcementLevel": "mandatory"
      }
    }

Would it make more sense to provide a "group" object, or should there be an object per policy pack?

Also related, support for Preview: #16