NKP opnemen in RHACS: Nutanix Kubernetes Platform beveiligen naast OpenShift

Een veelvoorkomend misverstand: RHACS zou alleen op OpenShift werken. Dat klopt niet helemaal — maar de nuance is belangrijk, zeker als je (zoals bij onze SOC 1- en SOC 2-boeken) met een mix van OpenShift, vanilla Kubernetes én Nutanix Kubernetes Platform (NKP) werkt.

Dit artikel behandelt zowel hoe je een NKP-cluster daadwerkelijk aan RHACS toevoegt, als wat Red Hats officiële ondersteuningsmodel daarbij precies inhoudt.

Het onderscheid: Central versus Secured Cluster Services

RHACS bestaat uit twee logische groepen componenten, met een verschillend ondersteuningsniveau:

• Central (webconsole, API, beleidsengine) — getest, gekwalificeerd en volledig ondersteund uitsluitend op OpenShift Container Platform 4.
• Secured Cluster Services (Sensor, Scanner, Collector — de onderdelen die daadwerkelijk een cluster beveiligen) — inzetbaar op een bredere set Kubernetes-platformen, waaronder Amazon EKS, Google GKE, Microsoft AKS, en generieke CNCF-conforme Kubernetes-distributies.

Dit betekent concreet: Central draait op een OpenShift-cluster, maar diezelfde Central kan vervolgens meerdere, verschillende Kubernetes-clusters beveiligen — inclusief clusters die zelf geen OpenShift zijn.

Waar staat NKP hierin?

Nutanix Kubernetes Platform is een CNCF-conforme Kubernetes-distributie. Red Hat noemt NKP niet als apart genoemd, officieel geteste platform in de RHACS-supportmatrix (die expliciet OpenShift, EKS, GKE en AKS noemt) — maar de Secured Cluster Services draaien via de standaard Kubernetes-API, zonder OpenShift-specifieke afhankelijkheden. Voor CNCF-conforme platformen buiten de expliciet geteste lijst geldt Red Hats bredere derde-partijbeleid: RHACS als product wordt ondersteund, maar reproductie van platformspecifieke problemen kan een OpenShift-omgeving vereisen, en voor infrastructuurspecifieke kwesties verwijst Red Hat door naar de leverancier van dat platform (in dit geval Nutanix).

Examentip: Praktisch betekent dit: ga niet uit van een met naam genoemde "NKP-integratie" als los verkocht product — ga uit van "Secured Cluster Services werken op elk conform Kubernetes-platform, met een duidelijk andere supportafspraak dan bij OpenShift".

NKP opnemen in RHACS: stap voor stap

De daadwerkelijke stappen om een NKP-cluster aan RHACS toe te voegen zijn identiek aan het toevoegen van elk ander niet-OpenShift Kubernetes-cluster — er is geen apart NKP-specifiek proces. Hieronder elke stap met uitleg, in plaats van alles in één commandoblok te proppen.

Stap 1 — Een nieuw cluster registreren in Central

Log in op de RHACS Central-webconsole (die draait op je OpenShift-cluster) en ga naar Platform Configuration → Clusters → Secure a cluster. Kies voor een handmatige installatie — niet de Operator-methode, want die is specifiek voor OpenShift en bestaat niet voor NKP. Geef het cluster een herkenbare naam, bijvoorbeeld nkp-productie, zodat je het straks in het dashboard makkelijk terugvindt tussen je OpenShift-clusters.

Stap 2 — Het cluster-init bundle downloaden

Central genereert nu een cluster-init bundle: een zip-bestand met daarin de certificaten en configuratie waarmee het NKP-cluster zich straks veilig bij Central kan aanmelden. Dit bundle bevat twee dingen die je bij de volgende stappen nodig hebt:

• Een Kubernetes Secret-manifest (bijvoorbeeld cluster-init-secrets.yaml) — bevat de certificaten zelf
• Een Helm values-bestand (bijvoorbeeld cluster-init-bundle-values.yaml) — vertelt de Helm-installatie hóe die certificaten te gebruiken

Download het bundle en pak het lokaal uit vóórdat je verdergaat.

Stap 3 — Een aparte namespace aanmaken

RHACS-onderdelen (Sensor, Collector, de admission controller) draaien standaard in hun eigen namespace, geïsoleerd van je applicaties:

kubectl create namespace stackrox

"stackrox" is de historische productnaam van RHACS (het product heette voorheen StackRox) — vandaar dat deze naamgeving overal in de tooling terugkomt, ook al heet het product nu RHACS.

Stap 4 — De certificaten uit het bundle toepassen

Dit plaatst het Secret-manifest uit stap 2 in de zojuist aangemaakte namespace, zodat de RHACS-onderdelen zo dadelijk toegang hebben tot de juiste certificaten:

kubectl apply -f cluster-init-secrets.yaml -n stackrox

Stap 5 — De RHACS Helm-repository toevoegen

Voordat je de Secured Cluster Services kunt installeren, moet Helm weten waar die charts vandaan te halen — dit is een eenmalige stap per machine/cluster van waaruit je installeert:

helm repo add rhacs https://mirror.openshift.com/pub/rhacs/charts/
helm repo update

Stap 6 — Sensor, Collector en de admission controller installeren

Dit is de daadwerkelijke installatie: Helm gebruikt het chart uit stap 5, gecombineerd met het values-bestand uit stap 2 (dat verwijst naar de certificaten van stap 4), om alle benodigde RHACS-componenten op het NKP-cluster te zetten:

helm install stackrox-secured-cluster-services 
  rhacs/secured-cluster-services 
  --namespace stackrox 
  -f cluster-init-bundle-values.yaml 
  --set clusterName=nkp-productie

Kort wat hier gebeurt, regel voor regel:

• helm install stackrox-secured-cluster-services — de naam die je deze installatie zelf geeft (vrij te kiezen)
• rhacs/secured-cluster-services — welk Helm chart geïnstalleerd wordt (uit de repository van stap 5)
• --namespace stackrox — installeer alles in de namespace van stap 3
• -f cluster-init-bundle-values.yaml — gebruik de configuratie/certificaten-koppeling uit het bundle van stap 2
• --set clusterName=nkp-productie — de naam waarmee dit cluster straks in het Central-dashboard verschijnt (moet overeenkomen met de naam uit stap 1)

Stap 7 — Verifiëren dat het werkt

Ga terug naar Central → Platform Configuration → Clusters. Het NKP-cluster zou nu moeten verschijnen met status "Healthy" — dat bevestigt dat Sensor, Collector en de admission controller succesvol draaien en verbinding hebben met Central.

Praktijktip: Gebruik overal kubectl in plaats van oc voor deze stappen — NKP heeft geen OpenShift CLI. Alle Kubernetes-API-aanroepen die RHACS gebruikt zijn standaard Kubernetes, dus dit is verder geen aanpassing van het proces zelf, alleen van de command-line tool waarmee je het uitvoert.

Kan dit automatisch, zonder handmatige stappen per cluster?

De stappen hierboven zijn voor één cluster, handmatig. Voor een omgeving waar regelmatig nieuwe clusters bijkomen (OpenShift, vanilla Kubernetes, én NKP door elkaar) is dat op termijn niet houdbaar. RHACS zelf heeft geen "zelfregistratie"-functie — een cluster kan zich niet uit zichzelf bij Central aanmelden zonder de certificaten uit een cluster-init bundle. De automatisering komt dan ook niet uit RHACS, maar uit RHACM.

Het mechanisme: RHACM Policy met automatische afdwinging

RHACM kent een governance-raamwerk waarin een Policy (met een ConfigurationPolicy en remediationAction: enforce) gekoppeld wordt aan een Placement — een dynamische selectie van clusters, bijvoorbeeld "alle clusters in een bepaalde clusterset". Zodra een nieuw cluster aan RHACM wordt toegevoegd (geïmporteerd als managed cluster) en aan die selectie voldoet, dwingt RHACM automatisch af dat het gekoppelde object aanwezig is — in dit geval: de RHACS Secured Cluster Services. Dit patroon staat ook wel bekend als "GitOps by Policy": in plaats van een aparte pipeline te bouwen die per nieuw cluster iets uitrolt, gebruik je RHACM's eigen, al bestaande policy-afdwinging.

Examentip: Kom je nog voorbeelden tegen die "PlacementRule" gebruiken (met apiVersion apps.open-cluster-management.io)? Dat is de oudere, inmiddels deprecated API. Nieuwe policies horen de "Placement"-API te gebruiken (cluster.open-cluster-management.io) — functioneel hetzelfde doel, andere, actuele resource.

Wat dit concreet oplevert

• Een nieuw OpenShift-, Kubernetes-, of NKP-cluster wordt als managed cluster aan RHACM toegevoegd (handmatig of, voor OpenShift-clusters specifiek, via RHACM's eigen auto-import op basis van een DiscoveredCluster-object)
• Zodra dat cluster voldoet aan de Placement-selectie van de gekoppelde policy, installeert RHACM automatisch de RHACS Secured Cluster Services erop — zonder dat iemand handmatig de stappen van hierboven hoeft te herhalen
• Dit werkt platformonafhankelijk: de Secured Cluster Services-installatie zelf heeft immers, zoals eerder uitgelegd, geen OpenShift-specifieke afhankelijkheden

Zo configureer je dit concreet

Een werkende opzet bestaat uit vier onderdelen, allemaal aangemaakt op de hub cluster. RHACM kent standaard al twee clustersets: global (bevat automatisch élk managed cluster) en default. Voor "elk nieuw cluster, welk platform dan ook" is global de juiste keuze.

1. Een ManagedClusterSetBinding — koppelt de globale clusterset aan een namespace, een vereiste stap vóórdat een Placement er iets mee mag doen:

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  name: global
  namespace: rhacs-onboarding
spec:
  clusterSet: global

2. Een Placement — selecteert dynamisch alle clusters uit die clusterset (dus: elk cluster, ongeacht of het net vandaag is toegevoegd):

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: alle-clusters
  namespace: rhacs-onboarding
spec:
  clusterSets:
    - global

3. De Policy zelf — met een ConfigurationPolicy die afdwingt dat de stackrox-namespace bestaat op elk cluster (het eerste, verplichte onderdeel vóór de daadwerkelijke Sensor-installatie):

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-rhacs-namespace
  namespace: rhacs-onboarding
spec:
  remediationAction: enforce
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: rhacs-namespace-aanwezig
        spec:
          remediationAction: enforce
          severity: high
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Namespace
                metadata:
                  name: stackrox

4. Een PlacementBinding — koppelt de Policy uit stap 3 aan de Placement uit stap 2, en maakt de afdwinging daadwerkelijk actief:

apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-rhacs-namespace
  namespace: rhacs-onboarding
placementRef:
  name: alle-clusters
  kind: Placement
  apiGroup: cluster.open-cluster-management.io
subjects:
  - name: policy-rhacs-namespace
    kind: Policy
    apiGroup: policy.open-cluster-management.io

Examentip: Dit voorbeeld dwingt bewust alleen de namespace af, om het principe helder te houden. Voor de daadwerkelijke Sensor/Collector-installatie voeg je in de praktijk extra object-templates toe aan dezelfde ConfigurationPolicy — meestal de vooraf gerenderde manifesten uit `helm template rhacs/secured-cluster-services` (eenmalig gegenereerd, dan in Git gezet), aangezien ConfigurationPolicy losse Kubernetes-objecten afdwingt en niet standaard zelf een Helm-installatie uitvoert.

De grens: Central blijft een eenmalige, handmatige stap

Deze automatisering geldt voor het uitrollen van Secured Cluster Services naar nieuwe clusters — niet voor Central zelf. Central installeer je nog steeds eenmalig, bewust, op een OpenShift-cluster; dat is geen onderdeel dat je via elk nieuw cluster opnieuw zou willen laten afdwingen.

Examentip: Dit is een net iets ander automatiseringsniveau dan "volledig zero-touch" — RHACM automatiseert het uitrollen ván RHACS naar nieuwe clusters, maar het toevoegen van een cluster áán RHACM zelf is (behalve in specifieke OpenShift/HyperShift-scenario's met auto-import) meestal nog een bewuste, initiële stap. Verwar "automatisch uitgerold zodra het cluster er is" dus niet met "volledig zonder menselijke tussenkomst vanaf nul".

Wat dit betekent voor een gemengde omgeving

Een organisatie met zowel OpenShift- als NKP-clusters (een niet ongebruikelijke combinatie in een Nutanix-gecentreerde infrastructuur) kan met één RHACS Central (gehost op een OpenShift-cluster) de beveiliging van beide platformen centraliseren:

1. Central draait op een dedicated of gedeeld OpenShift-cluster
2. Voor elk te beveiligen cluster (OpenShift of NKP) genereer je in Central een cluster-init bundle
3. Die bundle installeert Sensor, Collector en de admission controller op het doelcluster — ongeacht of dat OpenShift of NKP is
4. Beleid, kwetsbaarhedenoverzicht en de netwerkgraaf tonen vervolgens gecombineerd de status van alle aangesloten clusters in één Central-dashboard

De praktische implicatie: je hebt sowieso een OpenShift-cluster nodig

Wie uitsluitend NKP-clusters heeft en geen enkel OpenShift-cluster, kan RHACS niet volledig los van OpenShift inzetten — Central zelf vereist OpenShift voor volledige ondersteuning. In de praktijk betekent dit vaak: een klein, dedicated OpenShift-cluster specifiek om Central te hosten, terwijl de daadwerkelijk te beveiligen workloads op NKP (of andere platformen) blijven draaien.

Relatie tot compliance (SOC 1/SOC 2)

Voor organisaties die compliance moeten aantonen over een gemengd platformlandschap is dit onderscheid direct relevant: de technische beveiligingscontroles (kwetsbaarhedenscanning, netwerksegmentatie-bewaking, runtime-detectie) zijn via Secured Cluster Services consistent beschikbaar op zowel OpenShift als NKP, ook al verschilt de formele Red Hat-supportafspraak per platform. Voor een auditor is vaak vooral relevant dát de controle bestaat en aantoonbaar werkt — niet welk specifiek supporttier eronder ligt.

Veelgestelde vragen

Kan ik Central zelf op NKP draaien, in plaats van op OpenShift?

Technisch is dit soms mogelijk, maar dan valt dit buiten de volledig geteste, ondersteunde configuratie van Red Hat. Voor productieomgevingen is dit af te raden; de aanbevolen aanpak is Central op OpenShift, met Secured Cluster Services op de overige platformen.

Werkt de netwerkgraaf ook op NKP-clusters?

Ja — de netwerkgraaf is een functie van Sensor/Collector, die op elk conform Kubernetes-platform draaien, dus ook op NKP. De visualisatie in Central toont dit gewoon samen met je OpenShift-clusters.