Klaster OKD (OpenShift) – Zarządzanie użytkownikami, uprawnieniami, metodami autoryzacji

IT Admin > Konteneryzacja > OpenShift > Klaster OKD (OpenShift) – Zarządzanie użytkownikami, uprawnieniami, metodami autoryzacji

Testowy klaster OKD (OpenShift)

Poniższy wpis bazuje na konfiguracji klastra przeprowadzonej wg. wpisu https://itadmin.vblog.ovh/klaster-okd-openshift-na-maszynach-wirtualnych-proxmox-opis-instalacji/

Autoryzacja przez htpasswd

Ponieważ kubeadmin jest obecnie jedynym dostępnym użytkownikiem klastra należy utworzyć nową metodą autoryzacji np. htpasswd i dodać w niej kolejnych użytkowników. Przygotowujemy więc listę użytkowników w pliku np. /home/bastuser/htpasswd

# na maszynie bastion
htpasswd -c -B -b /home/bastuser/htpasswd jan.kowalski 1234abcd.
htpasswd -b /home/bastuser/htpasswd anna.nowak 1234abcd.
htpasswd -b /home/bastuser/htpasswd adam.wojcik 1234abcd.
htpasswd -b /home/bastuser/htpasswd maria.wisniewska 1234abcd.

Sprawdzamy jakie są obecnie dostępne metody poświadczeń na klastrze 

 oc get oauth cluster -o yaml > /tmp/oauth_przed.yml
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    release.openshift.io/create-only: "true"
  creationTimestamp: "2024-11-23T18:55:34Z"
  generation: 1
  name: cluster
  ownerReferences:
  - apiVersion: config.openshift.io/v1
    kind: ClusterVersion
    name: version
    uid: f13123ba-fb3c-4458-9aa3-33c66bc40974
  resourceVersion: "1459"
  uid: 87b4cfa9-b751-4090-91f5-a07cea76a155
spec: {}

Utworzenie obiektu secret htpass-secret

Tworzymy nowy obiekt typu secret przechowujące dane logowania

 oc create secret generic htpass-secret --from-file=/home/bastuser/htpasswd -n openshift-config
 # lub
 oc create secret generic htpass-secret --from-file=/home/bastuser/htpasswd -n openshift-config --dry-run -o yaml > /tmp/htpss-secret.yml

Utworzenie nowej metody autoryzacji poświadczeń na klastrze

Tworzymy nową metodę poświadczeń na podstawie definicji w pliku yaml, który musimy przygotować

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: htpasswd_provider
    mappingMethod: claim
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpass-secret

oc apply -f /home/bastuser/htpasswd_provider.yaml

Czekamy na podniesienie się podów w projekcie openshift-config

oc get pods -n openshift-authentication

Sprawdzamy jakie są dostępne metody poświadczeń na klastrze po zmianach

oc get oauth cluster -o yaml > /tmp/oauth_po.yml
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"config.openshift.io/v1","kind":"OAuth","metadata":{"annotations":{},"name":"cluster"},"spec":{"identityProviders":[{"htpasswd":{"fileData":{"name":"htpass-secret"}},"mappingMethod":"claim","name":"htpasswd_provider","type":"HTPasswd"}]}}
    release.openshift.io/create-only: "true"
  creationTimestamp: "2024-11-23T18:55:34Z"
  generation: 2
  name: cluster
  ownerReferences:
  - apiVersion: config.openshift.io/v1
    kind: ClusterVersion
    name: version
    uid: f13123ba-fb3c-4458-9aa3-33c66bc40974
  resourceVersion: "1383278"
  uid: 87b4cfa9-b751-4090-91f5-a07cea76a155
spec:
  identityProviders:
  - htpasswd:
      fileData:
        name: htpass-secret
    mappingMethod: claim
    name: htpasswd_provider
    type: HTPasswd

Nowa metoda autoryzacji powinna pojawić się w konsoli graficznej OKD (OpenShift)

Utworzenie obiektów user i identity na klastrze

Logujemy się próbnie po kolei na nowych użytkownikach po to aby powstały odpowiadające im obiekty users i identity

oc login -u jan.kowalski -p 1234abcd. https://api.testcluster.okdlab.local:6443 --insecure-skip-tls-verify
oc login -u anna.nowak -p 1234abcd. https://api.testcluster.okdlab.local:6443 --insecure-skip-tls-verify
oc login -u adam.wojcik -p 1234abcd. https://api.testcluster.okdlab.local:6443 --insecure-skip-tls-verify
oc login -u maria.wisniewska -p 1234abcd. https://api.testcluster.okdlab.local:6443 --insecure-skip-tls-verify

Weryfikujemy czy nowi użytkownicy są już dostępni na klastrze

oc get users
oc get identity

Dodanie kolejnych użytkowników do metody htpasswd lub zmiana hasła użytkownika

Tworzymy nowy plik htpasswd z nowym użytkownikiem z nowym hasłem

htpasswd -c -B -b /home/bastuser/htpasswd krystyna.lewandowska 1234abcd.

lub istniejącym użytkownikiem ale ze zmienionym hasłem

htpasswd -c -B -b /home/bastuser/htpasswd jan.kowalski 4321abcd,

dopisujemy koniecznie to co jest obecnie w secrecie htpass-secret na końcu nowego pliku htpasswd aby istniejący użytkownicy zostali dopisani na końcu pliku htpasswd (usuwamy zdublowanych użytkowników w razie czego z pliku htpasswd)

oc get secrets htpass-secret -n openshift-config -ojsonpath='{.data.htpasswd}' | base64 -d >> /home/bastuser/htpasswd

Aktualizujemy obiekt secret htpass-secret na podstawie nowej zawartości pliku /home/bastuser/htpasswd

oc create secret generic htpass-secret \
    --from-file=htpasswd=/home/bastuser/htpasswd \
    -n openshift-config \
    --dry-run=client -o yaml | oc apply -f -

Weryfikacja zawartości zaktualizowanego obiektu secret htpass-secret

oc get secret htpass-secret -n openshift-config -o yaml
oc get secret htpass-secret -n openshift-config -o jsonpath='{.data.htpasswd}' | base64 -d

Przypisanie uprawnień użytkownikom

Przypisanie użytkowników do roli w klastrze

Sprawdzamy jakie role są obecnie dostępne na klastrze

oc get clusterroles | grep admin

Przypisujemy wybranemu użytkownikowi wybraną rolę np. cluster-admin

oc adm policy add-cluster-role-to-user cluster-admin jan.kowalski
oc adm policy add-cluster-role-to-user cluster-reader anna.nowak
oc adm policy add-cluster-role-to-user cluster-monitoring-operator adam.wojcik
# rola skupiona na odczytywaniu metryk klastra 
oc adm policy add-cluster-role-to-user cluster-status maria.wisniewska

Podgląd jakie funkcjonalności zapewnia wybrana rola

oc describe clusterrole cluster-reader
oc describe clusterrole cluster-status
oc describe clusterrole cluster-monitoring-operator
oc describe clusterrole cluster-admin

Sprawdzenie jakie role ma przypisane wybrany użytkownik

oc get clusterrolebindings -o json | jq '.items[] | select(.subjects[]?.name == "jan.kowalski") | {role: .roleRef.name, namespace: .metadata.namespace, user: .subjects[].name}'

Sprawdzenie jakie role ma przypisane wybrany użytkownik w wybranym projekcie o nazwie: wordpress

oc get rolebindings -n wordpress -o json | jq '.items[] | select(.subjects[]?.name == "jan.kowalski") | {role: .roleRef.name, namespace: .metadata.namespace, user: .subjects[].name}'

Przeszukanie ról wybranego użytkownika we wszystkich projektach

for ns in $(oc get namespaces -o jsonpath='{.items[*].metadata.name}'); do
    echo "Namespace: $ns"
    oc get rolebindings -n $ns -o json | jq '.items[] | select(.subjects[]?.name == "jan.kowalski") | {role: .roleRef.name, user: .subjects[].name}'
done

Usunięcie roli przypisanej do użytkownika

Jeśli chcemy usunąć przypisaną rolę cluster-status do użytkownika anna.nowak

oc adm policy remove-cluster-role-from-user cluster-status anna.nowak
oc adm policy remove-cluster-role-from-user cluster-admin anna.nowak

Utworzenie nowej roli w klastrze

(do uzupełnienia)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-reader
rules:
  - apiGroups: ["*"]  # All API groups
    resources: ["*"]  # All resource types
    verbs: ["get", "list", "watch"]  # Read-only verbs
  - nonResourceURLs: ["*"]
    verbs: ["get"]  # Allow read access to non-resource URLs
oc apply -f cluster-reader-new.yaml

Jeśli chcemy stworzyć nową rolę w klastrze np.

(dokończyć)

Przypisanie uprawnień użytkownikowi do konkretnego projektu zamiast całego klastra

Sprawdzany jakie role są dostępne do użycia. Najczęstsze role dla projektów to: admin, view, edit

# sprawdzany dostępne do użycia role np. view
oc get clusterroles | grep "view"
oc describe clusterrole view
# dodajemy uprawnienia konkretnym użytkownikom do konkretnego projektu w tym przykładzie o nazwie wordpress
oc adm policy add-role-to-user admin krystyna.lewandowska -n wordpress
oc adm policy add-role-to-user view jan.kowalski -n wordpress
oc adm policy add-role-to-user edit maria.wisniewska -n wordpress

Sprawdzamy jakie role są obecnie przypisane do konkretnego projektu np. wordpress

oc get rolebinding -n wordpress -o wide

Autoryzacja LDAP

sdsadsad

Konteneryzacja, OpenShift
Tags , ,