Prepare MKE for MSR Installation#

MKE enforces security controls that can block MSR PostgreSQL deployments when using the Zalando Postgres Operator. To meet MSR PostgreSQL security requirements, configure MKE using a least-privilege approach.

Preferred approach#

Install the Zalando Postgres Operator with the Spilo privileges disabled. MSR does not require privileged Postgres containers, so running Spilo in unprivileged mode aligns with Kubernetes security best practices and circumvents the need to modify the MKE admission policies.

Create a postgres-operator-values.yaml file:

configKubernetes:
  spilo_privileged: false
  spilo_allow_privilege_escalation: false

Parameter	Description
`spilo_privileged`	Controls whether the Spilo container runs in Kubernetes `privileged` mode. Privileged containers have host-level access and bypass most container isolation. MSR Postgres does not require privileged mode.
`spilo_allow_privilege_escalation`	Controls whether the Spilo container can gain additional privileges (for example, through `setuid` binaries). MSR does not rely on OS-level privilege escalation.

Mirantis recommends that you configure these parameters in the Helm values file rather than patching the MKE 4 validating admission policies, as MKE may revert the policies to their default values over time.

!!! note The postgres-operator-values.yaml file you created contains only the settings required by MSR. Helm merges these with the chart's built-in defaults, so any setting not listed in the file keeps its default value.

   To review the full set of available settings, run:

    ```bash
    helm show values postgres-operator \
      --repo https://opensource.zalando.com/postgres-operator/charts/postgres-operator
    ```

Install the Postgres Operator, passing the new postgres-operator-values.yaml file:

helm install postgres-operator postgres-operator \
  --repo https://opensource.zalando.com/postgres-operator/charts/postgres-operator \
  -n <namespace-name> \
  -f postgres-operator-values.yaml

Verify the Postgres Operator configuration:

kubectl get operatorconfiguration postgres-operator \
  -n <namespace-name> \
  -o custom-columns=NAME:.metadata.name,SPILO_APE:.configuration.kubernetes.spilo_allow_privilege_escalation,SPILO_PRIV:.configuration.kubernetes.spilo_privileged

Example output:

NAME                SPILO_APE   SPILO_PRIV
postgres-operator   false       false

After you install MSR, confirm that the security settings were inherited:

kubectl get sts msr-postgres \
  -n <namespace-name> \
  -o custom-columns=NAME:.metadata.name,SPILO_APE:'.spec.template.spec.containers[0].securityContext.allowPrivilegeEscalation',SPILO_PRIV:'.spec.template.spec.containers[0].securityContext.privileged'

Example output:

NAME           SPILO_APE   SPILO_PRIV
msr-postgres   false       false

Alternative approaches#

Mirantis recommends that you only use the MKE preparation approaches detailed herein if your environment requires you to run Postgres containers with elevated privileges.

Running Postgres with elevated privileges increases the security risk surface. It is not required for standard MSR installations, and thus you should only consider it when a documented, environment-specific requirement prevents the use of the recommended least-privilege configuration.

MKE 4 preparation#

To install MSR on MKE 4, you must modify the default validating admission policy to allow for the required PostgreSQL resources.

Apply the following patch to update the mke4-ucpauthz validating admission policy:

kubectl patch validatingadmissionpolicy -n <namespace-name> mke4-ucpauthz
{
  "spec": {
    "matchConditions": [
      {
        "name": "skip-spilo-statefulsets",
        "expression": "!(request.userInfo.username == \"system:serviceaccount:<namespace-name>:postgres-operator\" && request.resource.group == \"apps\" && request.resource.resource == \"statefulsets\" && (request.operation == \"CREATE\" || request.operation == \"UPDATE\"))"
      },
      {
        "name": "skip-spilo-pods",
        "expression": "!(request.userInfo.username == \"system:serviceaccount:kube-system:statefulset-controller\" && request.operation == \"CREATE\" && request.resource.group == \"\" && request.resource.resource == \"pods\" && object.metadata.ownerReferences.exists(r, r.kind == \"StatefulSet\" && r.name == \"msr-postgres\"))"
      }
    ]
  }
}'

MKE 3 preparation#

To install MSR on MKE 3, you must first configure both the default:postgres-operator user account and the default:postgres-pod service account in MKE 3 with the privileged permission.

To prepare MKE 3.x web UI for MSR installation:

Log in to the MKE web UI.
In the left-side navigation panel, click the drop-down to display the available options.
Click Admin Settings > Privileges.
Navigate to the User account privileges section.
Enter <namespace-name>:postgres-operator into the User accounts field.

Note

You can replace <namespace-name> with default to indicate the use of the default namespace.
Select the privileged checkbox.
Scroll down to the Service account privileges section.
Enter <namespace-name>:postgres-pod into the Service accounts field.

Note

You can replace <namespace-name> with default to indicate the use of the default namespace.
Select the privileged checkbox.
Click Save.
Info

For already deployed MSR instances, issue a rolling restart of the postgres-operator deployment:
```
kubectl rollout restart deploy/postgres-operator
```

To prepare MKE 3.x CLI for MSR installation:

Install jq command line and ensure that your MKE configuration file is accessible. Refer to Use an MKE configuration file for more details.
Set the nodeIP variable to the IP of any manager node:
```
nodeIP=10.20.30.40
```

Create a privileges configuration file. The following example uses the default namespace. Save the file, for example, as new_privs.txt. Note that leading spaces at the beginning of each line are allowed but not required.

priv_attributes_allowed_for_user_accounts = ["privileged"]
priv_attributes_user_accounts = ["default:postgres-operator"]
priv_attributes_allowed_for_service_accounts = ["privileged"]
priv_attributes_service_accounts = ["default:postgres-pod"]

Authenticate and download your MKE configuration file:

AUTHTOKEN=$(curl -sk -d '{"username":"admin","password":"PASSWORD"}' \
  https://${nodeIP}/auth/login | jq -r .auth_token) && curl -sk -X \
  GET "https://${nodeIP}/api/ucp/config-toml" -H  \
  "accept: application/toml" -H  "Authorization: Bearer $AUTHTOKEN" > config.toml

Update the config.toml file with the new privileges:

LinuxmacOS

sed -i '/^\[cluster_config\]/r priv_attributes.toml' config.toml

sed -i '.bak' '/^\[cluster_config\]/r priv_attributes.toml' config.toml

Optional. Review the config.toml file to verify the changes. Note that leading spaces are allowed but are not required.

Upload the new config to MKE:

curl -k -X \
  PUT -H  "accept: application/toml" -H "Authorization: Bearer $AUTHTOKEN" \
  --upload-file config.toml https://$nodeIP/api/ucp/config-toml

Verify the updated configuration in the MKE web UI:
1. Log in to the MKE web UI as an admin.
2. Navigate to Admin → Admin Settings → Orchestration
3. Scroll to User account privileges and verify that the privileged option is enabled.