OpenShift¶

Attune runs on OpenShift 4.x clusters with Kubernetes 1.32+. This guide covers OpenShift-specific installation, TLS profile integration, and security considerations.

Installation¶

Via OperatorHub (recommended for OpenShift)¶

OpenShift includes a built-in OperatorHub catalog. Search for Attune (OLM package name attune) in the web console under Operators > OperatorHub and click Install. The OLM bundle includes all CRDs, RBAC, and the operator deployment.

Field	Value
Display name	Attune
Package name	`attune`
CSV name	`attune.vX.Y.Z` (matches the release version)
Channel	`stable`
Catalog	Community Operators (`community-operator-index`)
OpenShift versions	4.19+ (Attune requires Kubernetes 1.32+)

CLI check on an OpenShift cluster:

oc get packagemanifests -n openshift-marketplace attune
# or
oc get packagemanifests -n openshift-marketplace | grep -i attune

Where to find it in a browser: use OperatorHub.io/operator/attune (same package name attune). That site is the public web listing for the community OLM package.

Red Hat Ecosystem Catalog website

catalog.redhat.com search URLs do not reliably surface community operators (and some query links drop the search terms on redirect). The OpenShift in-cluster Community Operators catalog is the source of truth for installability on OpenShift, not the public website product search. Prefer OperatorHub.io for browsing, or the console / CLI checks above for a live cluster.

Catalog filters

In OperatorHub filters, select the Community source if the list is large. Do not search for attune-operator; that is not the package or CSV name used in the catalog.

Via Helm¶

kubectl create namespace attune-system

helm install attune \
  oci://ghcr.io/attune-io/charts/attune \
  --namespace attune-system \
  --set openshift.enabled=true

The openshift.enabled=true flag adds OpenShift-specific RBAC (read access to config.openshift.io/apiservers) and enables TLS profile auto-detection. Without it, the operator runs with vanilla Kubernetes RBAC only.

TLS profile auto-detection¶

OpenShift clusters enforce a cluster-wide TLS security profile via the APIServer resource at config.openshift.io/v1. This profile controls the minimum TLS version and cipher suites for API server connections.

When openshift.enabled=true, Attune reads this profile at startup and configures its outbound Prometheus connections to match. This prevents TLS handshake failures when the cluster enforces a stricter profile than Go's defaults.

OpenShift TLS Profile	Minimum TLS Version	Go equivalent
Modern	TLS 1.3	`tls.VersionTLS13`
Intermediate (default)	TLS 1.2	`tls.VersionTLS12`
Old	TLS 1.0	`tls.VersionTLS10`
Custom	Parsed from `custom.minTLSVersion`	e.g. `VersionTLS13` -> `tls.VersionTLS13`

How it works¶

On startup, the operator checks if the config.openshift.io/v1 API group exists via API discovery
If found, it reads the APIServer/cluster resource to extract the TLS security profile type
The detected minimum TLS version is applied to all outbound Prometheus HTTP connections
If the API is not found (vanilla Kubernetes) or the read fails, the operator falls back to Go defaults (TLS 1.2)

Verifying TLS profile detection¶

Check the operator logs at startup:

kubectl logs -n attune-system deploy/attune -c manager | grep -i tls

On OpenShift with an Intermediate profile:

{"level":"info","msg":"Detected OpenShift TLS profile","profile":"Intermediate","tlsMinVersion":"0x0303"}

On vanilla Kubernetes, no TLS-related messages appear at the default log level (the fallback to Go defaults is silent). Enable debug logging to confirm:

{"level":"debug","msg":"OpenShift config API not found, using Go TLS defaults"}

Security Context Constraints¶

The Attune Helm chart sets a restrictive security context by default:

podSecurityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 65532
  runAsGroup: 65532

These settings are compatible with the OpenShift restricted-v2 SCC (the default for non-privileged workloads). No custom SCC is required.

RBAC differences¶

When openshift.enabled=false (default), the ClusterRole contains only standard Kubernetes API permissions. When openshift.enabled=true, one additional rule is added:

- apiGroups:
    - config.openshift.io
  resources:
    - apiservers
  verbs:
    - get

This is read-only access to the cluster TLS configuration. The operator never writes to OpenShift API resources.

OLM installations

When installing via OperatorHub/OLM, the ClusterServiceVersion (CSV) bundle always includes the OpenShift RBAC rule. OLM manages the RBAC lifecycle automatically.

Thanos Querier¶

OpenShift Cluster Monitoring exposes Thanos Querier at https://thanos-querier.openshift-monitoring.svc:9091. That port expects a Kubernetes bearer token with cluster-monitoring-view (or cluster-monitoring-metrics-api).

The Prometheus HTTP client is the Attune manager, not each AttunePolicy. OperatorHub and the kustomize install send the attune-prometheus-query ServiceAccount token. Bind cluster-monitoring-view to that account. Helm binds the manager ServiceAccount unless prometheusAuth.queryServiceAccount.create is true. Do not copy a token Secret into every application namespace, and do not set bearerTokenSecret on cluster AttuneDefaults (that name is still looked up next to the policy).

Helm:

openshift:
  enabled: true
  bindClusterMonitoringView: true

That creates a ClusterRoleBinding to cluster-monitoring-view and passes --prometheus-use-service-account-token. Set the Thanos address on AttuneDefaults (operator auth is not attached to auto-discovered Prometheus). Prefer also:

prometheusAuth:
  queryServiceAccount:
    create: true

so Thanos gets a query-only identity instead of the manager token. A guardrail written on an AttunePolicy is then limited to that policy's namespace. A guardrail on cluster AttuneDefaults is not rewritten. Keep address and TLS on AttuneDefaults:

apiVersion: attune.io/v1alpha1
kind: AttuneDefaults
metadata:
  name: cluster-defaults
spec:
  metricsSource:
    prometheus:
      address: https://thanos-querier.openshift-monitoring.svc:9091
      tls:
        insecureSkipVerify: true

Prefer a proper CA over insecureSkipVerify when you have the service CA bundle. NetworkPolicy egress includes port 9091 when OpenShift integration or bindClusterMonitoringView is on.

OperatorHub and the kustomize install create a query ServiceAccount named attune-prometheus-query, a Role that lets the manager TokenRequest that account, and they pass --prometheus-query-service-account=attune-prometheus-query and --prometheus-use-service-account-token. Bind cluster-monitoring-view to the query account:

oc adm policy add-cluster-role-to-user cluster-monitoring-view \
  -z attune-prometheus-query -n <operator-namespace>

Thanos then receives the query account token. The manager token stays on the controller.

A long-lived token Secret in the operator namespace is Helm prometheusAuth.existingSecret (--prometheus-bearer-token-secret). Use that for Mimir or Grafana Cloud, not for Thanos Querier.

Combining with other features¶

OpenShift integration works alongside all other Attune features:

FIPS 140-3 mode (fips.enabled=true): Common on OpenShift clusters in regulated environments. The TLS profile detection respects the FIPS-approved cipher suites.
Prometheus Operator: OpenShift clusters typically include the Prometheus Operator. Enable metrics.serviceMonitor.enabled=true for automatic scrape target registration.
NetworkPolicy: The default NetworkPolicy allows egress to Prometheus (9090) and the Kubernetes API. OpenShift Thanos Querier adds egress to port 9091 when openshift.enabled or bindClusterMonitoringView is true.
GitOps (OpenShift GitOps / Argo CD): Default in-place resize does not update Git or Deployment templates. After a rollout, new pods start from Git resources until Attune re-resizes. For durable sizes across deploys, use Recommend + export ConfigMaps and kubectl attune diff -o yaml to open PRs, or opt into templatePersistence only if you accept live template mutation. See the GitOps integration guide.