Project, oc und ServiceAccount in OpenShift

1 Project vs Namespace

Ein Namespace ist in reinem Kubernetes nur eine Hülle. Ein Project ist dieselbe Hülle plus Selbstbedienung.

oc new-project erzeugt zuerst einen ProjectRequest – das einzige Objekt, das ein Nicht-Admin anlegen darf. Das project-request-Template (liegt in openshift-config, editierbar) legt daraufhin den Namespace plus die admin-RoleBinding für dich an. Ein Project ist keine stärkere Isolation als ein Namespace – nur ein paar Annotationen plus die automatische Bindung. Echte Netz-Trennung kommt separat über NetworkPolicy (F2).

2 oc new-project live verfolgen

Ein frisches Project, und alles ansehen, was dabei automatisch entsteht.

oc new-project demo-fundament
oc whoami
oc get rolebinding -n demo-fundament
# -> admin-Binding auf dich, plus system:image-builder/system:deployer fuer builder/deployer

oc get sa -n demo-fundament
# -> default, builder, deployer - schon da, ohne dass du etwas getan hast

oc get ns demo-fundament -o yaml | grep -A5 annotations

Die ServiceAccounts kommen nicht aus dem Template, sondern von Cluster-Controllern nach der Namespace-Erstellung (A6). Wichtige Annotationen am Namespace: openshift.io/sa.scc.uid-range, .mcs, .supplemental-groups (setzt die zufällige UID für Pods, A7), dazu openshift.io/description, display-name und requester. Der Namespace bekommt automatisch Zugriff auf die SCC restricted-v2 – über die clusterweite Gruppe system:authenticated, nicht extra pro Project.

3 Was bewusst nicht entsteht

Wer das für alle Projects will, trägt es ins project-request-Template ein. Über mehrere Projects hinweg geht eine ClusterResourceQuota per Label-Selektor.

Bleibt ein gelöschter Namespace ewig in Terminating, klemmt meist ein Finalizer – nachsehen mit oc get ns demo-fundament -o yaml im Feld spec.finalizers.

4 oc, kubectl und die API-Gruppen

oc ist kubectl plus die OpenShift-eigenen Verben – dieselbe Binary redet auch mit reinem Kubernetes.

Eine CRD registriert einen neuen Typ – danach ist kind: PostgresCluster gleichwertig zu Pod und wird genauso mit oc get bedient (D2). Genau so kommen Operatoren zu neuen Ressourcentypen.

5 Die API selbst erkunden

Ohne Doku herausfinden, was ein Cluster kann – drei Befehle.

# alle Typen: Kurzname, apiVersion, NAMESPACED, KIND
oc api-resources
oc api-resources --namespaced=false   # nur Cluster-Objekte

# Schema-Referenz direkt aus DIESEM Cluster, nicht aus der Doku:
oc explain route.spec.tls
oc explain route.spec.tls.termination

# eine kubeconfig hat drei Teile: Cluster, User, Context
oc config view --minify
echo $KUBECONFIG

Eine kubeconfig besteht aus Cluster (Adresse und CA), User (Token oder x509-Zertifikat) und Context (welcher Cluster, welcher Namespace). oc login schreibt die Datei, oc project <name> setzt darin den Namespace.

6 Das ServiceAccount-Modell

Drei Identitätsarten, alle drei RBAC-Subjekte (A5): User (aus dem IdP, A4), Group, und ServiceAccount.

Der Pod bekommt ein projiziertes Volume unter /var/run/secrets/kubernetes.io/serviceaccount/ mit den Dateien token, ca.crt und namespace. Das Bound Token ist kurzlebig (etwa eine Stunde), an eine audience gebunden, wird über die TokenRequest-API geholt und automatisch rotiert – nicht anfassen. Früher (bis OCP 4.15) hatte jede SA ein nie ablaufendes Token-Secret in etcd.

7 Eine ServiceAccount live anlegen

Anlegen, binden, Token prüfen – der Weg, den auch die Bibliothek-Pipeline geht.

oc create sa demo-sa -n demo-fundament
oc describe sa demo-sa -n demo-fundament

# startet ohne jedes Recht:
oc auth can-i get pods --as=system:serviceaccount:demo-fundament:demo-sa -n demo-fundament   # no

# Rolle binden (-z = ServiceAccount im aktuellen Namespace):
oc adm policy add-role-to-user edit -z demo-sa -n demo-fundament
oc auth can-i get pods --as=system:serviceaccount:demo-fundament:demo-sa -n demo-fundament   # yes

# ein statisches Token nur fuer externe Nutzer (z.B. eine CI ausserhalb):
oc create token demo-sa -n demo-fundament --duration=1h

# Pull-Secret anhaengen:
oc secrets link demo-sa <secret> --for=pull -n demo-fundament

automountServiceAccountToken: false an SA oder Pod setzen, wenn der Pod die API gar nicht ruft – die meisten App-Pods brauchen kein Token. Die SCC kommt von der SA, nicht vom User – oc adm policy add-scc-to-user anyuid -z demo-sa steuert den erlaubten securityContext (A7).

8 Typische Fallen

9 Wie die Bibliothek es macht

OCP-Unterschied bei allen dreien: keiner – Project-Selbstbedienung, oc/API-Gruppen/Konsole und das ServiceAccount-Modell sind Kern-OpenShift bzw. Kern-Kubernetes, identisch auf OKD und OCP.

+ Die Kurzfassung