# OCP scc helm charting

## Role Template

# role.yaml
{{- if .Values.anyuid.enabled -}}
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: {{ include "general-template.roleName" . }}
rules:
- apiGroups: ["security.openshift.io"]
  resources: ["securitycontextconstraints"]
  verbs: ["use"]
  resourceNames: ["anyuid"]
{{- end }}

## RoleBinding Template

# rolebinding.yaml
{{- if .Values.anyuid.enabled -}}
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: {{ include "general-template.roleBindingName" . }}
subjects:
- kind: ServiceAccount
  name: {{ include "general-template.serviceAccountName" . }}
roleRef:
  kind: Role
  name: {{ include "general-template.roleName" . }}
  apiGroup: rbac.authorization.k8s.io
{{- end }}

## Values Additions

anyuid:
  enabled: true
  name: ""

# README

**Guide for Using Anyuid Role in Helm Chart:**

1. **Purpose of Anyuid Role:**
- The anyuid Role and RoleBinding in this Helm chart facilitate the attachment of the `anyuid` Security Context Constraints (SCC) to a specific Service Account within an OpenShift environment.
- This is useful when the associated application or service requires elevated privileges, such as the ability to run containers with arbitrary user IDs and supplementary group IDs.

2. **How to Enable the Anyuid Feature:**
- To enable the anyuid feature, set the following values in your Helm chart's `values.yaml`:

anyuid:
  enabled: true
  name: ""  # Provide a specific name if needed

- Deploy or upgrade the Helm chart with the feature using the appropriate Helm commands.

3. **Cautions When Using Anyuid Role:**
- **Security Implications:**
- Granting anyuid privileges allows containers to run with the potential to escalate privileges, posing security risks. Only enable this feature for trusted applications.
- **Namespace Scope:**
- Ensure that the anyuid Role and RoleBinding are applied within the correct namespace. Anyuid privileges granted will be scoped to that namespace.
- **Service Account Specific:**
- The anyuid feature is tied to a specific Service Account. Be cautious when applying it to Service Accounts used by critical applications.

4. **Best Practices:**
- **Limit Usage:**
- Minimize the usage of anyuid privileges to only where necessary.
- **Audit and Monitor:**
- Regularly audit and monitor applications using anyuid privileges to detect and respond to potential security issues.

5. **Disabling Anyuid:**
- If the anyuid feature is no longer required, set the `anyuid.enabled` value to `false` in the `values.yaml` file and redeploy or upgrade the Helm chart.

By following these guidelines, you can leverage the anyuid feature while being aware of the associated security considerations and best practices. Always assess the necessity of elevated privileges and exercise caution when applying anyuid roles.