OpenSHift Deployment errors

Milchbroetchen

Milchbroetchen

Hello :-)
Hi,
ich habe ein laufendes OpenShift Cluster, in diesem habe ich Rook-CEPH installiert inkl. CSI Driver um PV/PVC zu verwalten, dies funktioniert alles ohne Probleme. Nun habe ich den GitLab Operator installiert und unter Create Instance eine GitLab Instanz erstellt. Alle Deployments wurden erstellt, jedoch bekomme ich bei der gitlab-nginx-ingress-controller Deployment folgenden error.

Code: 
pods "gitlab-nginx-ingress-controller-675bdb4f8-" is forbidden: unable
        to validate against any security context constraint: [provider "anyuid":
        Forbidden: not usable by user or serviceaccount,
        spec.containers[0].securityContext.runAsUser: Invalid value: 101: must
        be in the ranges: [1000730000, 1000739999],
        spec.containers[0].securityContext.capabilities.add: Invalid value:
        "NET_BIND_SERVICE": capability may not be added, provider "nonroot":
        Forbidden: not usable by user or serviceaccount, provider
        "hostmount-anyuid": Forbidden: not usable by user or serviceaccount,
        provider "machine-api-termination-handler": Forbidden: not usable by
        user or serviceaccount, provider "hostnetwork": Forbidden: not usable by
        user or serviceaccount, provider "hostaccess": Forbidden: not usable by
        user or serviceaccount, provider "rook-ceph": Forbidden: not usable by
        user or serviceaccount, provider "node-exporter": Forbidden: not usable
        by user or serviceaccount, provider "rook-ceph-csi": Forbidden: not
        usable by user or serviceaccount, provider "privileged": Forbidden: not
        usable by user or serviceaccount]

Weshalb in diesem Deployment die Pods nicht hochkommen, ich habe aber aktuell keine Idee wie ich dieses Problem lösen könnte. Hat von euch jemand eine Idee oder sogar einmal das selbe Problem gehabt.

mfg
Ich
 
Sorry für den Dopelpost.

Leide bekomme ich diesen error bei fast allen Deployments die ich durchführe auf OpenShift. Habe da langsam auch keine Ahnung mehr was ich falsch mache.

Code: 
pods "harbor-registry-core-5764d7b57d-" is forbidden: unable to validate
        against any security context constraint: [provider "anyuid": Forbidden:
        not usable by user or serviceaccount, provider restricted:
        .spec.securityContext.fsGroup: Invalid value: []int64{10000}: 10000 is
        not an allowed group, spec.containers[0].securityContext.runAsUser:
        Invalid value: 10000: must be in the ranges: [1000680000, 1000689999],
        provider "nonroot": Forbidden: not usable by user or serviceaccount,
        provider "hostmount-anyuid": Forbidden: not usable by user or
        serviceaccount, provider "machine-api-termination-handler": Forbidden:
        not usable by user or serviceaccount, provider "hostnetwork": Forbidden:
        not usable by user or serviceaccount, provider "hostaccess": Forbidden:
        not usable by user or serviceaccount, provider "rook-ceph": Forbidden:
        not usable by user or serviceaccount, provider "node-exporter":
        Forbidden: not usable by user or serviceaccount, provider
        "rook-ceph-csi": Forbidden: not usable by user or serviceaccount,
        provider "privileged": Forbidden: not usable by user or serviceaccount]

Dies ist ein Deployment von Harbor welches ich über Helm v3 angestoßen habe.
 
Openshift versucht deine Pods zu deployen aber wird durch die standardmässigen SCC (Security Context Constraints) jedes Openshift-Projektes blockiert da die UID im Container nicht der auto-generierten UID entspricht.

Leider sind eine ganze Reihe von Deployments und Helmcharts nicht automatisch kompatibel mit Openshift's Pragma dass jedes Projekt eine eigene UserID erhält. Hier gibt es ein paar Möglichkeiten, ich gehe kurz drauf ein:

A) Dem Projekt das SCC geben
Auswahl zb: nonroot (jede UID ausser root) oder anyuid (jede UID inklusive Root)
Dies ist sicherlich am einfachsten, reduziert aber potentiell die Sicherheit auf 2 Etagen:
- deine FSGroups sind nicht mehr einzigartig im Cluster, es ist somit zumindest einfacher auf die Daten zu kommen falls sie auf einem nicht-usergeschützten Medium wie NFS liegen.
- Die Ideologie der UID-Trennung und damit zusätzlichen Sicherheitsschicht ist zumindest reduziert
Bei Projekten wo du den Inhalten vertraust -also wenn es nicht grade ein Container hinter 5 Ecken auf Dockerhub ist - ist das aber durchaus gangbar.
Code: 
oc adm policy add-scc-to-user nonroot system:serviceaccount:<dein-projekt>:default
Achtung: Entgegen der grotesken Empfehlung einiger ansonsten reputabler Softwareschmieden, keineswegs einfach nonroot oder anyuid auf dem ganzen Cluster erlauben. Dann kann man auch Openshift direkt in die Tonne kloppen und ein 0815 K8S installieren :p

B) Das Projekt "openshift-korrekt" konfigurierens
Bei Harbor (und einigen anderen Deployments auch) bevorzuge ich das Bitnami Helmchart gegenüber dem Original da es etwas flexibler ist, bei gleichzeitig auch exzellenter Aktualität. Bitnami ist ein Projekt von Vmware und damit durchaus zuverlässig und vertrauenswürdig.
Die Optionen sind afaik nicht alle im Original-Chart enthalten.

Für Harbor wäre in deiner values.yml bei zu setzen:
YAML: 
containerSecurityContext:
  runAsUser: 1000680000
podSecurityContext:
  fsGroup: 1000680000

redis:  #Falls verwendet
  master:
    containerSecurityContext:
      runAsUser: 1000680000
    podSecurityContext:
      fsGroup: 1000680000

postgresql: #Falls verwendet
  containerSecurityContext:
    runAsUser: 1000680000
    enabled: true
  securityContext:
    enabled: true
    fsGroup: 1000680000

Da diese Variablen nicht immer klar dokumentiert sind, finde ich es generell am einfachsten "helm template harbor harbor -f values.yml > harbor.out" das Deployment als Datei zu generieren und aus diesem dann auf das originale (Sub)chart zu schliessen, dort dann die values.yml zu betrachten. Etwas kompliziert kann es natürlich schon werden ;)
Das Problem ist generell dass nicht alle Variablen der Helm Subcharts im Hauptchart reflektiert werden, man also etwas Erfahrung (und manchmal Ratespiel) braucht um die Konfigurationsvariablen zu interpretieren und setzen.
 
Ok, ich blicke da noch nicht ganz durch, ich muss also quasi dem Projekt andere rechte zuweisen? Entweder über die values.yaml oder über dem oc adm Befehl?
 
Milchbroetchen said:
ich muss also quasi dem Projekt andere rechte zuweisen?
Click to expand...
Nein, du musst nicht. Das ist nur eine der möglichen Optionen - die einfachste aber gleichzeitig am meisten von OKD/OCP abweichenste.
Über die genannte values.yml Parameter erklärst du dem Helmchart und damit dem Container wie er sich zu benehmen hat um mit Openshift klar zu kommen.
 
Leider bekomme ich bei meinem GitLab Runner nach wie vor errors wenn ich einen Job ausführen möchte. Alles andere läuft ohne Probleme.

ERROR: Job failed (system failure): prepare environment: setting up credentials: secrets is forbidden: User "system:serviceaccount:gitlab-runner:gitlab-runner-sa" cannot create resource "secrets" in API group "" in the namespace "gitlab-runner". Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information
Click to expand...
Ich frage mich warum er keine Ressourcen erstellen kann, der Runner hat voll rechte. Wie in der Doku beschrieben, habe ich Ihm auch folgendes gegeben.
oc adm policy add-scc-to-user anyuid -z gitlab-runner-sa
Click to expand...
 
You must log in or register to reply here.
Back
Top