OpenShift User Namespaces voor Iedereen

Sudo Friday OpenShift UserNameSpaces K8S scc
  Wander Boessenkool

In het verleden hebben wij op dit kanaal al naar OpenShift User Namespaces gekeken, toen ze in versie 4.17 voor het eerst als Technology Preview (TP) verschenen. Toen moest je als admin nog door wat hoepeltjes heenspringen: Een FeatureGate activeren waardoor je cluster niet meer kon updaten, de container engine omzetten naar crun, en wat ander kunst en vliegwerk.

Nu, met OpenShift 4.20, is de feature General Availability (GA) geworden, en kan iedereen het gebruiken. Dit is goed, en mooi, en wat meer superlatieven, maar Wander heeft er nog steeds wat commentaar op.

Zo is het met de standaard documentatie (en nieuwe Security Context Constraint (SCC) restricted-v3) nog steeds niet mogelijk om zonder extra containers als een nep-root te laten draaien, of elk ander UID/GID onder de 1000. En juist voor dat soort dingen is dit een erg mooie oplossing.

Gelukkig zijn er daar oplossing voor. Zo zou je de lijst toegestane UIDs kunnen aanpassen, maar dan moet je met een tool als Kyverno hostUsers: false gaan afdwingen.

Wander stelt een andere oplossing voor: Een custom SCC die het gebruik van willekeurige UIDs en GIDs toestaat, maar dan alleen wanneer je User Namespaces gebruikt in je pod.

De gebruikte manifesten voor de custom SCC kun je onder de video terugvinden.

De gebruikte manifesten

scc.yaml

 1apiVersion: security.openshift.io/v1
 2metadata:
 3  annotations:
 4    include.release.openshift.io/ibm-cloud-managed: "true"
 5    include.release.openshift.io/self-managed-high-availability: "true"
 6    include.release.openshift.io/single-node-developer: "true"
 7    kubernetes.io/description: |
 8      `userns` is specifically made to allow teams to run containers with fixed
 9      UIDs and GIDs (even root), but only in a user namespace, shielding the
10      host from their actions.      
11  name: userns
12allowHostDirVolumePlugin: false
13allowHostIPC: false
14allowHostNetwork: false
15allowHostPID: false
16allowHostPorts: false
17allowPrivilegeEscalation: true
18allowPrivilegedContainer: false
19allowedCapabilities:
20- NET_BIND_SERVICE
21defaultAddCapabilities: null
22fsGroup:
23  ranges:
24  - max: 65534
25  type: MustRunAs
26groups: []
27kind: SecurityContextConstraints
28priority: null
29readOnlyRootFilesystem: false
30requiredDropCapabilities: null
31runAsUser:
32  type: RunAsAny
33seLinuxContext:
34  type: MustRunAs
35seccompProfiles:
36- runtime/default
37supplementalGroups:
38  type: RunAsAny
39userNamespaceLevel: RequirePodLevel
40users: []
41volumes:
42- configMap
43- csi
44- downwardAPI
45- emptyDir
46- ephemeral
47- persistentVolumeClaim
48- projected
49- secret

clusterrolebinding.yaml

 1apiVersion: rbac.authorization.k8s.io/v1
 2kind: ClusterRoleBinding
 3metadata:
 4  annotations:
 5  name: system:openshift:scc:userns
 6roleRef:
 7  apiGroup: rbac.authorization.k8s.io
 8  kind: ClusterRole
 9  name: system:openshift:scc:userns
10subjects:
11- apiGroup: rbac.authorization.k8s.io
12  kind: Group
13  name: system:authenticated

Gerelateerde posts

Horizontal Pod Autoscalers Uitgelegd

In het verleden hebben we hier op dit kanaal al eens gekeken naar het automatisch schalen van je applicaties aan de hand van custom metrics. Maar dat waren custom metrics, en met Keda. De basis, de standaard Kubernetes HorizontalPodAutoscaler, hebben we nog niet behandeld.

Kustomize Resource Versionering

Wanneer je Kustomize gebruikt om je Kubernetes applicaties (of configuraties) uit te rollen kun je tegen het probleem aanlopen dat je een wijziging wilt maken aan je bases of je components, maar zonder dat deze tegelijk al je verschillende omgevingen raakt. Gelukkig gebruikt Kustomize voor het ophalen van externe resources een handige library genaamd go-getter die met een simpele syntax verschillende Git revisies kan ophalen.

Statuspagina's versus Dashboards

Dashboards en statuspagina’s zijn twee verschillende dingen. Een dashboard is bedoeld voor beheerders en laat gedetailleerde statistieken zien die gebruikt kunnen worden voor correlatie. Een statuspagina is daarentegen bedoeld voor eindgebruikers, en laat een simpel beschikbaar/niet beschikbaar zien. Wanneer je eenb statuspagina wilt toevoegen aan je infrastructuur dan heb je een hoop keuzes uit self-hosted (open-source) paketten, en betaalde diensten die door third-parties gehost worden. ZO kun je bijvoorbeeld beginnen met het overzicht van Awesome Status Pages op GitHub. Wander vond daarentegen dat er iets simpels miste dat je met een enkel configuratie bestand ergens in een container of een VM kon draaien, specifiek geënt op OpenShift/Kubernetes of andere dingen die je met Prometheus kunt monitoren. In deze video laat hij openshift-status zien, een klein tooltje dat een statuspagina voor één of meerdere clusters maakt aan de hand van Prometheus queries. Geen externe databases, of andere dependencies, alleen een enkele binary en een configuratie bestand.