---
title: automate-selinux-volume-relabel-workaround
authors:
- mrunalp
reviewers: # Include a comment about what domain expertise a reviewer is expected to bring and what area of the enhancement you expect them to focus on. For example: - "@networkguru, for networking aspects, please look at IP bootstrapping aspect"
- jan
- rphillips

approvers:
- TBD
api-approvers: # In case of new or modified APIs or API extensions (CRDs, aggregated apiservers, webhooks, finalizers). If there is no API change, use "None"
- TBD
creation-date: 2022-11-04
last-updated: 2022-11-04
tracking-link: # link to the tracking ticket (for example: Jira Feature or Epic ticket) that corresponds to this enhancement
- TBD

---

# Automate SELinux volume relabel workaround(s)

## Summary
Automate the application of SELinux volume relabel workarounds as
described in https://access.redhat.com/solutions/6221251, so it
doesn't involve touching all of the affected pods.

## Motivation

A growing number of users are hitting the issue of relabeling taking
a long time as their volumes grow in number of files. We want to make
it easier for these customers to deploy the workaround until the
issue is fixed in kubernetes upstream.

### User Stories

As an OpenShift cluster admin, I want to automate the deployment
of the SELinux relabel workaround, so the users don't have to
manually edit their workloads.

### Goals

- Provide an automated way to apply the workaround that reduces
the configuration changes needed on the workloads.

### Non-Goals

- Absolute zero configuration be required.
- This is deployed by default on all clusters.

## Proposal

An admission hook will be developed that will apply the workarounds
in a configurable list of namespaces (projects) to workloads that have
PersistentVolumeClaims in them.

This admission hook could potentially be made a part of the
cluster resource override operator.

### Workflow Description

1. Cluster admin determines that users have workloads affected by the issue.
2. Cluster admin deployes the admission hook on the clusters for user's namespaces
via a label or a ConfigMap.
4. Users are able to deploy the workloads in the namespaces that admin configured
and don't hit the issue anymore.

## Alternatives considered
#### Deploy Gatekeeper and configure Gatekeeper mutation.
For e.g.

apiVersion: mutations.gatekeeper.sh/v1
kind: Assign
metadata:
  name: set-spc
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    scope: Namespaced
    kinds:
    - apiGroups: ["*"]
      kinds: ["Pod"]
    namespaces: ["acme"]
  location: "spec.securityContext.seLinuxOptions.type"
  parameters:
    assign:
      value: "spc_t"

This is ruled out as we don't support Gatekeeper in OpenShift as a product
so we can't ensure that it doesn't break as OpenShift updates are deployed.

#### Disable SELinux
This is also an option but reduces the security of the cluster as a whole.

### Implementation Details/Notes/Constraints [optional]

This should be similar to other hooks in OpenShift today.

### Risks and Mitigations

What are the risks of this proposal and how do we mitigate. Think broadly. For
example, consider both security and how this will impact the larger OKD
ecosystem.

How will security be reviewed and by whom?

How will UX be reviewed and by whom?

Consider including folks that also work outside your immediate sub-project.

### Drawbacks

The workloads will run spc_t and will have more privileges
if they manage to break out of the container.

If the customer doesn't have a lot of workloads or are able
to identify the workloads ahead of time, then it isn't too
hard for them to apply the workaround directly.

We will have to come up with a migration plan for these
volumes once this is fixed upstream.

## Design Details

### Open Questions [optional]

- Is there a preference for one of the two workarounds?
- Are users okay with marking the namespaces?
- Migration details.

### Test Plan

**Note:** *Section not required until targeted at a release.*
- Test with the hook deployed to ensure it is applied to the correct
workloads.