Despre Linux

  • Facebook
  • Twitter
  • LinkedIn
  • Acasă
  • Linux
    • Comenzi Linux
    • Tutoriale
  • Kubernetes
  • RHCSA
    • Exerciții RHCSA
    • SELinux
    • Permisiuni
  • General
    • Open source
  • Contact

Utilizatori și certificate în Kubernetes. Crearea unui CertificateSigningRequest

2 august 2021 By Bobses Un comentariu

Autentificarea prin certificate în Kubernetes este o parte extrem de importantă procesului de securizare a întregului cluster. Autentificarea definește CINE poate accesa un cluster, folosind diferite metode (fișiere cu username și parolă sau username și tokens, certificate, LDAP, ServiceAccounts).

În acest articol voi arăta cum se poate crea un certificat și o cheie de autentificare la un cluster Kubernetes pentru un user oarecare - să-l numim, cu totul întâmplător, bobses; request-ul de certificat pentru acest utilizator va fi semnat în 2 moduri: manual și automat.

Premise

Prescurtări folosite:

  • CA = Certificate Authorithy
  • CRT = Certificat
  • CSR = Certificate Signing Request
  • Key = Cheie privată
  • CN = Common Name

În Kubernetes, conturile sunt de 2 tipuri:

  • ServiceAccount (de exemplu, este folosit de poduri pentru a accesa resursele k8s) - sunt gestionate de API-ul kubernetes
  • Normal User - nu este o resursă kubernetes; este cineva care deține un certificat și o cheie. Acest certificat al unui user normal trebuie să fie semnat de CA-ul clusterului k8s. În certificatul clientului, username-ul trebuie trecut sub Common Name (CN): /CN=bobses

Cum obținem un certificat semnat de kubernetes

În mare, procedura recomandată presupune să avem un CSR creat cu comanda openssl. Includem acest CSR în resursa kubernetes numită CertificateSigningRequest, resursă care este trimisă ulterior la API-ul k8s, care folosește CA-ul clusterului pentru a semna și emite certificatul.

CertificateSigningRequest

Această procedură o putem considera semnare automată și este mult mai sigură și mai ușoară decât, să spunem, descărcarea CA din clusterul k8s și semnarea individuală a fiecărui certificat (manuală).

Imaginile de mai jos ilustrează ceea ce se întâmplă în ambele situații:

Semnarea manuală
semnare manuală CSR
Semnarea automată
semnare automată CRT

Invalidarea unui certificat în kubernetes

Nu există nicio modalitate de a invalida un certificat - dacă un certificat a fost semnat și emis, el poate fi folosit până la expirare.

În cazul în care bănuim că avem o scurgere de informații și vrem să ștergem toate drepturile pe care un certificat le dă unui utilizator, putem apela la RBAC - jonglăm cu drepturile userului respectiv din roluri și rolebindings.

O altă modalitate, greoaie și de evitat, este generarea unui alt CA pentru clusterul k8s și regenerarea tuturor celorlalte certificate.

Exerciții

  1. Crearea unei chei private pentru utilizatorul bobses
  2. Generarea CSR pentru userul bobses pe baza cheii private anterioare
  3. Semnarea manuală a CSR-ului folosind CA-ul din kubernetes pentru generarea CRT
  4. Semnarea automată a CSR: crearea unei resurse CSR în k8s , semnarea folosind API-ul k8s, apoi descărcarea certificatului
  5. Conectarea la API-ul kbernetes folosind cheia privată de la pasul 1 și certificatul obținut manual sau automat (pașii 3 și 4).

1. Crearea cheii private (KEY)

openssl genrsa -out bobses.key 2048

2. Crearea request-ului (CSR)

openssl req -new -key bobses.key -out bobses.csr

În acest moment, avem 2 fișiere: cheia privată bobses.key și CSR-ul bobses.csr

Generare CSR

3. Semnarea manuală

Căutăm în cluster locul unde se află Certificate Authorithy (de obicei, îl găsim în /etc/kubernetes/pki/ca.crt):

find /etc/kubernetes/pki | grep ca.crt

Comanda de semnare (indicăm fișierul .csr, fișierul ca.crt, cheia privată ca.key a clusterului k8s, dar și fișierul unde va rezulta certificatul semnat):

openssl x509 -req -in bobses.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out bobses.crt -days 500

În cazul în care folosiți clusterul k3s construit în contul free tier de la Oracle Cloud, acesta se află la /var/lib/rancher/k3s/server/tls/server-ca.crt, iar comanda va fi:

openssl x509 -req -in bobses.csr -CA /var/lib/rancher/k3s/server/tls/server-ca.crt -CAkey /var/lib/rancher/k3s/server/tls/server-ca.key -CAcreateserial -out bobses.crt -days 500

Observăm că a apărut și certificatul bobses.crt:

Semnare manuala CSR

Pentru a verifica validitatea noului certificat, se poate da comanda:

openssl x509 -in bobses.crt -text -noout

Verificare certificat CRT

Conținutul certificatului poate fi văzut cu comanda cat bobses.crt.

4. Semnare automată via API

a. Trebuie să creăm o resursă kubernetes de tip CertificateSigningRequest. Fișierul manifest va fi de forma:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: bobses
spec:
  groups:
  - system:authenticated
  request: {{CSR_CODAT_BASE_64}}  ## aici se trece hashul base64 al csr-ului generat la pasul 2
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth

La request se va trece hash-ul base64 al fisierului bobses.csr generat la pasul 2:

cat bobses.csr | base64 | tr -d "\n"

Instalăm fișierul .yaml de mai sus:

kubectl apply -f bobses-auto.yaml

Vizualizăm resursele de tip certificatesigningrequest din cluster - observăm statusul Pending al noii resurse instalate:

kubectl get certificatesigningrequest

b. Aprobăm CSR-ul aflat în starea Pending cu comanda:

kubectl certificate approve bobses

Semnare automata CSR folosind API k8s

c. Obținerea și descărcarea certificatului:

kubectl get csr bobses -ojsonpath="{.status.certificate}" | base64 -d > bobses-auto.crt

Documentația oficială se află aici: https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/

5. Conectarea la clusterul k8s

Folosim comenzile de mai jos (atenție la numele clusterului!) - definim userul bobses, contextul bobses și setăm contextul folosit:

kubectl config set-credentials bobses --client-key=bobses.key --client-certificate=bobses.crt
kubectl config set-context bobses --cluster=default --user=bobses
kubectl config get-contexts
kubectl config use-context bobses

La final, remarcăm că userul bobses, deși se conectează prin intermediul unor certificate în kubernetes (este autentificat), nu are absolut niciun drept (nu poate nici măcar să listeze noduri, poduri sau namespace-uri):

Pentru a-i acorda userului bobses anumite permisiuni in cluster, vom folosi autorizarea RBAC și vom defini CE poate să facă userul bobses după autentificare - dar asta în articolul următor.

Concluzii

Automatizând aprobarea CSR prin intermediul API-ului kubernetes, eliminăm accesul direct la CA-ul din cluster. Accesul la CA din cluster trebuie să fie minim, căci prin intermediul lui se creează certificate trusted pentru întregul cluster k8s.

Partajează asta:

  • Dă clic pentru a partaja pe Facebook(Se deschide într-o fereastră nouă)
  • Dă clic pentru a partaja pe LinkedIn(Se deschide într-o fereastră nouă)
  • Dă clic pentru a partaja pe Twitter(Se deschide într-o fereastră nouă)

Similare

Din categoria: Tutoriale Etichete: certificate, k8s, kubernetes, RBAC

Trackbacks

  1. Din nou despre RBAC în Kubernetes | Despre Linux spune:
    4 august 2021 la 8:32

    […] Verificare folosind un user existent bobses creat ca în acest articol. […]

    Răspunde

Lasă un răspuns Anulează răspunsul

Acest site folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.

Copyright © 2023 · Bobses

Administrează consimțămintele pentru cookie-uri
Pentru a oferi cea mai bună experiență, folosim tehnologii, cum ar fi cookie-uri, pentru a stoca și/sau accesa informațiile despre dispozitive. Consimțământul pentru aceste tehnologii ne permite să procesăm date, cum ar fi comportamentul de navigare sau ID-uri unice pe acest site. Dacă nu îți dai consimțământul sau îți retragi consimțământul dat poate avea afecte negative asupra unor anumite funcționalități și funcții.
Funcționale Mereu activ
Stocarea tehnică sau accesul sunt strict necesare în scopul legitim de a permite utilizarea unui anumit serviciu cerut în mod explicit de către un abonat sau un utilizator sau în scopul exclusiv de a executa transmiterea unei comunicări printr-o rețea de comunicații electronice.
Preferințe
Stocarea tehnică sau accesul este necesară în scop legitim pentru stocarea preferințelor care nu sunt cerute de abonat sau utilizator.
Statistici
Stocarea tehnică sau accesul care sunt utilizate exclusiv în scopuri statistice. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
Stocarea tehnică sau accesul sunt necesare pentru a crea profiluri de utilizator pentru a trimite publicitate sau pentru a urmări utilizatorul pe un site web sau pe mai multe site-uri web în scopuri de marketing similare.
Administrează opțiunile Administrează serviciile Administrează vânzătorii Citește mai multe despre aceste scopuri
Vizualizează preferințele
{title} {title} {title}