കുബർനെറ്റസിലെ എബിസി ഓഫ് സെക്യൂരിറ്റി: ആധികാരികത, അംഗീകാരം, ഓഡിറ്റിംഗ്

താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട്, ഏതെങ്കിലും സിസ്റ്റത്തിൻ്റെ പ്രവർത്തനത്തിൽ, സുരക്ഷയുടെ പ്രശ്നം ഉയർന്നുവരുന്നു: ആധികാരികത ഉറപ്പാക്കൽ, അവകാശങ്ങളുടെ വേർതിരിവ്, ഓഡിറ്റിംഗ്, മറ്റ് ജോലികൾ. കുബെർനെറ്റസിനായി ഇതിനകം സൃഷ്‌ടിച്ചതാണ് നിരവധി പരിഹാരങ്ങൾ, വളരെ ആവശ്യപ്പെടുന്ന ചുറ്റുപാടുകളിൽ പോലും മാനദണ്ഡങ്ങൾ പാലിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന... K8-കളുടെ അന്തർനിർമ്മിത സംവിധാനങ്ങൾക്കുള്ളിൽ നടപ്പിലാക്കിയിട്ടുള്ള സുരക്ഷയുടെ അടിസ്ഥാന വശങ്ങൾക്കായി അതേ മെറ്റീരിയൽ നീക്കിവച്ചിരിക്കുന്നു. ഒന്നാമതായി, കുബർനെറ്റുമായി പരിചയപ്പെടാൻ തുടങ്ങുന്നവർക്ക് ഇത് ഉപയോഗപ്രദമാകും - സുരക്ഷയുമായി ബന്ധപ്പെട്ട പ്രശ്നങ്ങൾ പഠിക്കുന്നതിനുള്ള ഒരു ആരംഭ പോയിൻ്റായി.

പ്രാമാണീകരണം

കുബർനെറ്റസിൽ രണ്ട് തരം ഉപയോക്താക്കളുണ്ട്:

• സേവന അക്കൗണ്ടുകൾ - കുബർനെറ്റസ് API നിയന്ത്രിക്കുന്ന അക്കൗണ്ടുകൾ;
• ഉപയോക്താക്കൾ — ബാഹ്യവും സ്വതന്ത്രവുമായ സേവനങ്ങൾ നിയന്ത്രിക്കുന്ന "സാധാരണ" ഉപയോക്താക്കൾ.

ഈ തരങ്ങൾ തമ്മിലുള്ള പ്രധാന വ്യത്യാസം, സേവന അക്കൗണ്ടുകൾക്ക് കുബർനെറ്റസ് API-യിൽ പ്രത്യേക ഒബ്‌ജക്റ്റുകൾ ഉണ്ട് എന്നതാണ് (അവയെ അങ്ങനെ വിളിക്കുന്നു - ServiceAccounts), ഒരു നെയിംസ്‌പെയ്‌സുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നതും സീക്രട്ട്‌സ് തരത്തിലുള്ള ഒബ്‌ജക്‌റ്റുകളിൽ ക്ലസ്റ്ററിൽ സംഭരിച്ചിരിക്കുന്ന അംഗീകാര ഡാറ്റയുടെ ഒരു കൂട്ടവും. അത്തരം ഉപയോക്താക്കൾ (സർവീസ് അക്കൗണ്ടുകൾ) പ്രാഥമികമായി കുബെർനെറ്റസ് ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്ന പ്രക്രിയകളുടെ കുബർനെറ്റസ് API-യിലേക്കുള്ള ആക്സസ് അവകാശങ്ങൾ നിയന്ത്രിക്കാൻ ഉദ്ദേശിച്ചുള്ളതാണ്.

സാധാരണ ഉപയോക്താക്കൾക്ക് Kubernetes API-ൽ എൻട്രികൾ ഇല്ല: അവ ബാഹ്യ സംവിധാനങ്ങളാൽ നിയന്ത്രിക്കപ്പെടണം. അവ ക്ലസ്റ്ററിന് പുറത്ത് ജീവിക്കുന്ന ആളുകൾക്കോ ​​പ്രക്രിയകൾക്കോ ​​വേണ്ടിയുള്ളതാണ്.

ഓരോ API അഭ്യർത്ഥനയും ഒരു സേവന അക്കൗണ്ട്, ഒരു ഉപയോക്താവ് എന്നിവയുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു അല്ലെങ്കിൽ അജ്ഞാതമായി കണക്കാക്കപ്പെടുന്നു.

ഉപയോക്തൃ പ്രാമാണീകരണ ഡാറ്റ ഉൾപ്പെടുന്നു:

• ഉപയോക്തൃനാമം - ഉപയോക്തൃനാമം (കേസ് സെൻസിറ്റീവ്!);
• യുഐഡി - "ഉപയോക്തൃനാമത്തേക്കാൾ കൂടുതൽ സ്ഥിരതയുള്ളതും അതുല്യവുമായ" മെഷീൻ-റീഡബിൾ യൂസർ ഐഡൻ്റിഫിക്കേഷൻ സ്ട്രിംഗ്;
• ഗ്രൂപ്പുകൾ - ഉപയോക്താവ് ഉൾപ്പെടുന്ന ഗ്രൂപ്പുകളുടെ ലിസ്റ്റ്;
• അധികമായ - അംഗീകാര സംവിധാനം ഉപയോഗിക്കാവുന്ന അധിക ഫീൽഡുകൾ.

Kubernetes-ന് ധാരാളം പ്രാമാണീകരണ സംവിധാനങ്ങൾ ഉപയോഗിക്കാൻ കഴിയും: X509 സർട്ടിഫിക്കറ്റുകൾ, ബെയറർ ടോക്കണുകൾ, പ്രാമാണീകരണ പ്രോക്സി, HTTP അടിസ്ഥാന ഓത്ത്. ഈ മെക്കാനിസങ്ങൾ ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ധാരാളം അംഗീകാര സ്കീമുകൾ നടപ്പിലാക്കാൻ കഴിയും: പാസ്വേഡുകളുള്ള ഒരു സ്റ്റാറ്റിക് ഫയൽ മുതൽ OpenID OAuth2 വരെ.

മാത്രമല്ല, ഒരേസമയം നിരവധി അംഗീകാര സ്കീമുകൾ ഉപയോഗിക്കാൻ കഴിയും. സ്ഥിരസ്ഥിതിയായി, ക്ലസ്റ്റർ ഉപയോഗിക്കുന്നത്:

• സേവന അക്കൗണ്ട് ടോക്കണുകൾ - സേവന അക്കൗണ്ടുകൾക്കായി;
• X509 - ഉപയോക്താക്കൾക്കായി.

സർവീസ് അക്കൌണ്ടുകൾ കൈകാര്യം ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള ചോദ്യം ഈ ലേഖനത്തിൻ്റെ പരിധിക്കപ്പുറമാണ്, എന്നാൽ ഈ പ്രശ്നം കൂടുതൽ വിശദമായി പരിചയപ്പെടാൻ ആഗ്രഹിക്കുന്നവർക്ക്, ആരംഭിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു ഔദ്യോഗിക ഡോക്യുമെൻ്റേഷൻ പേജുകൾ. X509 സർട്ടിഫിക്കറ്റുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന പ്രശ്നം ഞങ്ങൾ സൂക്ഷ്മമായി പരിശോധിക്കും.

ഉപയോക്താക്കൾക്കുള്ള സർട്ടിഫിക്കറ്റുകൾ (X.509)

സർട്ടിഫിക്കറ്റുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നതിനുള്ള ക്ലാസിക് മാർഗം ഉൾപ്പെടുന്നു:

• പ്രധാന തലമുറ:

  mkdir -p ~/mynewuser/.certs/
  openssl genrsa -out ~/.certs/mynewuser.key 2048

• ഒരു സർട്ടിഫിക്കറ്റ് അഭ്യർത്ഥന സൃഷ്ടിക്കുന്നു:

  openssl req -new -key ~/.certs/mynewuser.key -out ~/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"

• Kubernetes ക്ലസ്റ്റർ CA കീകൾ ഉപയോഗിച്ച് ഒരു സർട്ടിഫിക്കറ്റ് അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുന്നു, ഒരു ഉപയോക്തൃ സർട്ടിഫിക്കറ്റ് നേടുന്നു (ഒരു സർട്ടിഫിക്കറ്റ് ലഭിക്കുന്നതിന്, സ്ഥിരസ്ഥിതിയായി സ്ഥിതി ചെയ്യുന്ന Kubernetes ക്ലസ്റ്റർ CA കീയിലേക്ക് ആക്‌സസ് ഉള്ള ഒരു അക്കൗണ്ട് നിങ്ങൾ ഉപയോഗിക്കണം. /etc/kubernetes/pki/ca.key):

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

• ഒരു കോൺഫിഗറേഷൻ ഫയൽ സൃഷ്ടിക്കുന്നു:
  • ക്ലസ്റ്റർ വിവരണം (ഒരു നിർദ്ദിഷ്ട ക്ലസ്റ്റർ ഇൻസ്റ്റാളേഷനായി CA സർട്ടിഫിക്കറ്റ് ഫയലിൻ്റെ വിലാസവും സ്ഥാനവും വ്യക്തമാക്കുക):

    kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443

  • അല്ലെങ്കിൽ എങ്ങനെ അല്ലശുപാർശ ചെയ്‌ത ഓപ്ഷൻ - നിങ്ങൾ റൂട്ട് സർട്ടിഫിക്കറ്റ് വ്യക്തമാക്കേണ്ടതില്ല (അപ്പോൾ kubectl ക്ലസ്റ്ററിൻ്റെ api-സെർവറിൻ്റെ കൃത്യത പരിശോധിക്കില്ല):

    kubectl config set-cluster kubernetes  --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443

  • കോൺഫിഗറേഷൻ ഫയലിലേക്ക് ഒരു ഉപയോക്താവിനെ ചേർക്കുന്നു:

    kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt  --client-key=.certs/mynewuser.key

  • സന്ദർഭം ചേർക്കുന്നു:

    kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

  • ഡിഫോൾട്ട് സന്ദർഭ അസൈൻമെൻ്റ്:

    kubectl config use-context mynewuser-context

മുകളിലുള്ള കൃത്രിമത്വങ്ങൾക്ക് ശേഷം, ഫയലിൽ .kube/config ഇതുപോലുള്ള ഒരു കോൺഫിഗറേഷൻ സൃഷ്ടിക്കപ്പെടും:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://192.168.100.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: target-namespace
    user: mynewuser
  name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
  user:
    client-certificate: /home/mynewuser/.certs/mynewuser.crt
    client-key: /home/mynewuser/.certs/mynewuser.key

അക്കൗണ്ടുകൾക്കും സെർവറുകൾക്കുമിടയിൽ കോൺഫിഗറേഷൻ കൈമാറുന്നത് എളുപ്പമാക്കുന്നതിന്, ഇനിപ്പറയുന്ന കീകളുടെ മൂല്യങ്ങൾ എഡിറ്റുചെയ്യുന്നത് ഉപയോഗപ്രദമാണ്:

• certificate-authority
• client-certificate
• client-key

ഇത് ചെയ്യുന്നതിന്, നിങ്ങൾക്ക് അടിസ്ഥാന 64 ഉപയോഗിച്ച് അവയിൽ വ്യക്തമാക്കിയ ഫയലുകൾ എൻകോഡ് ചെയ്യാനും കോൺഫിഗറിൽ രജിസ്റ്റർ ചെയ്യാനും കീകളുടെ പേരിൽ സഫിക്സ് ചേർക്കാനും കഴിയും. -data, അതായത്. ലഭിച്ചിട്ടുണ്ട് certificate-authority-data അതുപോലെ തന്നെ.

kubeadm ഉള്ള സർട്ടിഫിക്കറ്റുകൾ

റിലീസിനൊപ്പം കുബേർനെറ്റ്സ് 1.15 അതിൻ്റെ പിന്തുണയുടെ ആൽഫ പതിപ്പിന് നന്ദി, സർട്ടിഫിക്കറ്റുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നത് വളരെ എളുപ്പമായി kubeadm യൂട്ടിലിറ്റി. ഉദാഹരണത്തിന്, ഉപയോക്തൃ കീകൾ ഉപയോഗിച്ച് ഒരു കോൺഫിഗറേഷൻ ഫയൽ സൃഷ്ടിക്കുന്നത് ഇപ്പോൾ ഇങ്ങനെയായിരിക്കാം:

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: ആവശ്യമാണ് വിലാസം പരസ്യം ചെയ്യുക സ്ഥിരസ്ഥിതിയായി സ്ഥിതിചെയ്യുന്ന api-സെർവർ കോൺഫിഗറേഷനിൽ കണ്ടെത്താനാകും /etc/kubernetes/manifests/kube-apiserver.yaml.

തത്ഫലമായുണ്ടാകുന്ന കോൺഫിഗറേഷൻ stdout-ലേക്ക് ഔട്ട്പുട്ട് ചെയ്യും. അതിൽ സേവ് ചെയ്യേണ്ടതുണ്ട് ~/.kube/config ഉപയോക്തൃ അക്കൗണ്ട് അല്ലെങ്കിൽ ഒരു പരിസ്ഥിതി വേരിയബിളിൽ വ്യക്തമാക്കിയ ഫയലിലേക്ക് KUBECONFIG.

ആഴത്തില് കുഴിക്കുക

വിവരിച്ചിരിക്കുന്ന പ്രശ്നങ്ങൾ കൂടുതൽ വിശദമായി മനസ്സിലാക്കാൻ ആഗ്രഹിക്കുന്നവർക്ക്:

• പ്രത്യേക ലേഖനം ഔദ്യോഗിക Kubernetes ഡോക്യുമെൻ്റേഷനിൽ സർട്ടിഫിക്കറ്റുകൾക്കൊപ്പം പ്രവർത്തിക്കുമ്പോൾ;
• ബിറ്റ്നാമിയിൽ നിന്നുള്ള നല്ല ലേഖനം, അതിൽ സർട്ടിഫിക്കറ്റുകളുടെ പ്രശ്നം ഒരു പ്രായോഗിക വീക്ഷണകോണിൽ നിന്ന് സ്പർശിക്കുന്നു.
• പൊതുവായ ഡോക്യുമെൻ്റേഷൻ കുബെർനെറ്റസിലെ പ്രാമാണീകരണത്തെക്കുറിച്ച്.

അംഗീകാരം

സ്ഥിരസ്ഥിതി അംഗീകൃത അക്കൗണ്ടിന് ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കാനുള്ള അവകാശമില്ല. അനുമതികൾ നൽകുന്നതിന്, കുബർനെറ്റസ് ഒരു അംഗീകാര സംവിധാനം നടപ്പിലാക്കുന്നു.

പതിപ്പ് 1.6-ന് മുമ്പ്, കുബെർനെറ്റസ് ഒരു അംഗീകാര തരം ഉപയോഗിച്ചിരുന്നു എബിഎസി (ആട്രിബ്യൂട്ട് അടിസ്ഥാനമാക്കിയുള്ള ആക്സസ് നിയന്ത്രണം). അതിനെക്കുറിച്ചുള്ള വിശദാംശങ്ങൾ ഇതിൽ കാണാം ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ. ഈ സമീപനം നിലവിൽ പാരമ്പര്യമായി കണക്കാക്കപ്പെടുന്നു, എന്നാൽ മറ്റ് പ്രാമാണീകരണ തരങ്ങൾക്കൊപ്പം നിങ്ങൾക്ക് ഇത് തുടർന്നും ഉപയോഗിക്കാം.

ഒരു ക്ലസ്റ്ററിലേക്കുള്ള ആക്സസ് അവകാശങ്ങളെ വിഭജിക്കുന്ന നിലവിലെ (കൂടുതൽ വഴക്കമുള്ള) രീതിയെ വിളിക്കുന്നു RBAC (റോൾ അടിസ്ഥാനമാക്കിയുള്ള ആക്സസ് നിയന്ത്രണം). പതിപ്പ് മുതൽ ഇത് സ്ഥിരതയുള്ളതായി പ്രഖ്യാപിച്ചു കുബേർനെറ്റ്സ് 1.8. RBAC ഒരു അവകാശ മാതൃക നടപ്പിലാക്കുന്നു, അതിൽ വ്യക്തമായി അനുവദനീയമല്ലാത്ത എല്ലാം നിരോധിച്ചിരിക്കുന്നു.
RBAC പ്രവർത്തനക്ഷമമാക്കാൻ, നിങ്ങൾ പാരാമീറ്റർ ഉപയോഗിച്ച് Kubernetes api-server ആരംഭിക്കേണ്ടതുണ്ട് --authorization-mode=RBAC. പാരാമീറ്ററുകൾ മാനിഫെസ്റ്റിൽ api-സെർവർ കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് സജ്ജീകരിച്ചിരിക്കുന്നു, അത് സ്ഥിരസ്ഥിതിയായി പാതയിൽ സ്ഥിതിചെയ്യുന്നു /etc/kubernetes/manifests/kube-apiserver.yaml, വിഭാഗത്തിൽ command. എന്നിരുന്നാലും, RBAC ഇതിനകം സ്ഥിരസ്ഥിതിയായി പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നു, അതിനാൽ നിങ്ങൾ അതിനെക്കുറിച്ച് വിഷമിക്കേണ്ടതില്ല: മൂല്യം ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഇത് പരിശോധിക്കാനാകും authorization-mode (ഇതിനകം സൂചിപ്പിച്ചതിൽ kube-apiserver.yaml). വഴിയിൽ, അതിൻ്റെ അർത്ഥങ്ങൾക്കിടയിൽ മറ്റ് തരത്തിലുള്ള അംഗീകാരങ്ങൾ ഉണ്ടാകാം (node, webhook, always allow), എന്നാൽ ഞങ്ങൾ അവരുടെ പരിഗണന മെറ്റീരിയലിൻ്റെ പരിധിക്ക് പുറത്ത് വിടും.

വഴിയിൽ, ഞങ്ങൾ ഇതിനകം പ്രസിദ്ധീകരിച്ചു ഒരു ലേഖനം ആർബിഎസിയുമായി പ്രവർത്തിക്കുന്നതിൻ്റെ തത്വങ്ങളെയും സവിശേഷതകളെയും കുറിച്ച് വിശദമായ വിവരണത്തോടെ, അതിനാൽ കൂടുതൽ അടിസ്ഥാനകാര്യങ്ങളുടെയും ഉദാഹരണങ്ങളുടെയും ഒരു ഹ്രസ്വ പട്ടികയിലേക്ക് ഞാൻ എന്നെത്തന്നെ പരിമിതപ്പെടുത്തും.

RBAC വഴി കുബർനെറ്റസിലെ ആക്‌സസ് നിയന്ത്രിക്കാൻ ഇനിപ്പറയുന്ന API എൻ്റിറ്റികൾ ഉപയോഗിക്കുന്നു:

• Role и ClusterRole - ആക്സസ് അവകാശങ്ങൾ വിവരിക്കുന്ന റോളുകൾ:
• Role ഒരു നെയിംസ്പേസിൽ അവകാശങ്ങൾ വിവരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു;
• ClusterRole - ക്ലസ്റ്ററിനുള്ളിൽ, നോഡുകൾ, നോൺ-റിസോഴ്‌സ് url പോലുള്ള ക്ലസ്റ്റർ-നിർദ്ദിഷ്ട ഒബ്‌ജക്റ്റുകൾ ഉൾപ്പെടെ (അതായത്, കുബർനെറ്റസ് ഉറവിടങ്ങളുമായി ബന്ധപ്പെട്ടതല്ല - ഉദാഹരണത്തിന്, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - ബൈൻഡിംഗിനായി ഉപയോഗിക്കുന്നു Role и ClusterRole ഒരു ഉപയോക്താവിലേക്കോ ഉപയോക്തൃ ഗ്രൂപ്പിലേക്കോ സേവന അക്കൗണ്ടിലേക്കോ.

റോളും റോൾ ബൈൻഡിംഗ് എൻ്റിറ്റികളും നെയിംസ്പേസിൽ പരിമിതപ്പെടുത്തിയിരിക്കുന്നു, അതായത്. ഒരേ നെയിംസ്പേസിൽ ആയിരിക്കണം. എന്നിരുന്നാലും, ഒരു RoleBinding-ന് ഒരു ClusterRole പരാമർശിക്കാൻ കഴിയും, ഇത് ഒരു കൂട്ടം പൊതുവായ അനുമതികൾ സൃഷ്ടിക്കാനും അവ ഉപയോഗിച്ച് ആക്സസ് നിയന്ത്രിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു.

റോളുകൾ ഇനിപ്പറയുന്ന നിയമങ്ങളുടെ സെറ്റ് ഉപയോഗിച്ച് അവകാശങ്ങളെ വിവരിക്കുന്നു:

• API ഗ്രൂപ്പുകൾ - കാണുക ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ apiGroups വഴിയും ഔട്ട്പുട്ടിലൂടെയും kubectl api-resources;
• വിഭവങ്ങൾ (വിഭവങ്ങൾ: pod, namespace, deployment ഇത്യാദി.);
• ക്രിയകൾ (ക്രിയകൾ: set, update മുതലായവ).
• ഉറവിട നാമങ്ങൾ (resourceNames) - നിങ്ങൾ ഒരു നിർദ്ദിഷ്ട ഉറവിടത്തിലേക്ക് ആക്സസ് നൽകേണ്ടിവരുമ്പോൾ, ഈ തരത്തിലുള്ള എല്ലാ ഉറവിടങ്ങളിലേക്കും അല്ല.

കുബർനെറ്റസിലെ അംഗീകാരത്തിൻ്റെ കൂടുതൽ വിശദമായ വിശകലനം പേജിൽ കാണാം ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ. പകരം (അല്ലെങ്കിൽ, ഇതിനുപുറമെ), അവളുടെ ജോലി വ്യക്തമാക്കുന്ന ഉദാഹരണങ്ങൾ ഞാൻ നൽകും.

RBAC എൻ്റിറ്റികളുടെ ഉദാഹരണങ്ങൾ

ലളിതം Role, ഇത് പോഡുകളുടെ ലിസ്റ്റും സ്റ്റാറ്റസും നേടാനും നെയിംസ്‌പെയ്‌സിൽ നിരീക്ഷിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു target-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: target-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ഉദാഹരണം: ClusterRole, ഇത് പോഡുകളുടെ ഒരു ലിസ്റ്റും സ്റ്റാറ്റസും നേടാനും ക്ലസ്റ്ററിലുടനീളം അവയെ നിരീക്ഷിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # секции "namespace" нет, так как ClusterRole задействует весь кластер
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

ഉദാഹരണം: RoleBinding, ഇത് ഉപയോക്താവിനെ അനുവദിക്കുന്നു mynewuser നെയിംസ്‌പെയ്‌സിലെ പോഡുകൾ "വായിക്കുക" my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # имя пользователя зависимо от регистра!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # здесь должно быть “Role” или “ClusterRole”
  name: pod-reader # имя Role, что находится в том же namespace,
                   # или имя ClusterRole, использование которой
                   # хотим разрешить пользователю
  apiGroup: rbac.authorization.k8s.io

ഇവൻ്റ് ഓഡിറ്റ്

ആസൂത്രിതമായി, കുബർനെറ്റസ് വാസ്തുവിദ്യയെ ഇനിപ്പറയുന്ന രീതിയിൽ പ്രതിനിധീകരിക്കാം:

അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതിന് ഉത്തരവാദിത്തമുള്ള പ്രധാന കുബർനെറ്റസ് ഘടകം api-സെർവർ. ക്ലസ്റ്ററിലെ എല്ലാ പ്രവർത്തനങ്ങളും അതിലൂടെ കടന്നുപോകുന്നു. ഈ ആന്തരിക സംവിധാനങ്ങളെക്കുറിച്ച് നിങ്ങൾക്ക് ലേഖനത്തിൽ കൂടുതൽ വായിക്കാം "നിങ്ങൾ kubectl റൺ പ്രവർത്തിപ്പിക്കുമ്പോൾ Kubernetes-ൽ എന്താണ് സംഭവിക്കുന്നത്?".

സ്ഥിരസ്ഥിതിയായി പ്രവർത്തനരഹിതമാക്കിയ കുബർനെറ്റസിലെ രസകരമായ ഒരു സവിശേഷതയാണ് സിസ്റ്റം ഓഡിറ്റിംഗ്. Kubernetes API-ലേക്ക് എല്ലാ കോളുകളും ലോഗ് ചെയ്യാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. നിങ്ങൾ ഊഹിക്കുന്നതുപോലെ, ക്ലസ്റ്ററിൻ്റെ അവസ്ഥ നിരീക്ഷിക്കുന്നതും മാറ്റുന്നതുമായി ബന്ധപ്പെട്ട എല്ലാ പ്രവർത്തനങ്ങളും ഈ API വഴിയാണ് നടത്തുന്നത്. അതിൻ്റെ കഴിവുകളെക്കുറിച്ചുള്ള ഒരു നല്ല വിവരണം (സാധാരണപോലെ) ഇതിൽ കാണാം ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ K8s. അടുത്തതായി, ഞാൻ വിഷയം ലളിതമായ ഭാഷയിൽ അവതരിപ്പിക്കാൻ ശ്രമിക്കും.

അങ്ങനെയാണെങ്കിൽ, ഓഡിറ്റിംഗ് പ്രവർത്തനക്ഷമമാക്കാൻ, Api-സെർവറിലെ കണ്ടെയ്‌നറിലേക്ക് ആവശ്യമായ മൂന്ന് പാരാമീറ്ററുകൾ ഞങ്ങൾ കൈമാറേണ്ടതുണ്ട്, അവ ചുവടെ കൂടുതൽ വിശദമായി വിവരിച്ചിരിക്കുന്നു:

• --audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
• --audit-log-path=/var/log/kube-audit/audit.log
• --audit-log-format=json

ആവശ്യമായ ഈ മൂന്ന് പാരാമീറ്ററുകൾ കൂടാതെ, ഓഡിറ്റിംഗുമായി ബന്ധപ്പെട്ട നിരവധി അധിക ക്രമീകരണങ്ങൾ ഉണ്ട്: ലോഗ് റൊട്ടേഷൻ മുതൽ വെബ്ഹുക്ക് വിവരണങ്ങൾ വരെ. ലോഗ് റൊട്ടേഷൻ പാരാമീറ്ററുകളുടെ ഉദാഹരണം:

• --audit-log-maxbackup=10
• --audit-log-maxsize=100
• --audit-log-maxage=7

എന്നാൽ ഞങ്ങൾ അവയിൽ കൂടുതൽ വിശദമായി വസിക്കില്ല - നിങ്ങൾക്ക് എല്ലാ വിശദാംശങ്ങളും കണ്ടെത്താനാകും kube-apiserver ഡോക്യുമെൻ്റേഷൻ.

ഇതിനകം സൂചിപ്പിച്ചതുപോലെ, എല്ലാ പാരാമീറ്ററുകളും api-സെർവർ കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് മാനിഫെസ്റ്റിൽ സജ്ജീകരിച്ചിരിക്കുന്നു (സ്ഥിരസ്ഥിതിയായി /etc/kubernetes/manifests/kube-apiserver.yaml), വിഭാഗത്തിൽ command. ആവശ്യമായ 3 പാരാമീറ്ററുകളിലേക്ക് മടങ്ങുകയും അവ വിശകലനം ചെയ്യുകയും ചെയ്യാം:

1. audit-policy-file — ഓഡിറ്റ് നയം വിവരിക്കുന്ന YAML ഫയലിലേക്കുള്ള പാത. ഞങ്ങൾ പിന്നീട് അതിൻ്റെ ഉള്ളടക്കത്തിലേക്ക് മടങ്ങും, എന്നാൽ ഇപ്പോൾ ഞാൻ ശ്രദ്ധിക്കുന്നത്, ഫയൽ api-സെർവർ പ്രോസസ്സ് വഴി വായിക്കാനാകുന്നതായിരിക്കണം. അതിനാൽ, ഇത് കണ്ടെയ്നറിനുള്ളിൽ മൌണ്ട് ചെയ്യേണ്ടത് ആവശ്യമാണ്, ഇതിനായി നിങ്ങൾക്ക് കോൺഫിഗറേഷൻ്റെ ഉചിതമായ വിഭാഗങ്ങളിലേക്ക് ഇനിപ്പറയുന്ന കോഡ് ചേർക്കാൻ കഴിയും:

     volumeMounts:
       - mountPath: /etc/kubernetes/policies
         name: policies
         readOnly: true
     volumes:
     - hostPath:
         path: /etc/kubernetes/policies
         type: DirectoryOrCreate
       name: policies

2. audit-log-path - ലോഗ് ഫയലിലേക്കുള്ള പാത. എപിഐ-സെർവർ പ്രക്രിയയിലേക്കും പാത ആക്‌സസ് ചെയ്യാവുന്നതായിരിക്കണം, അതിനാൽ ഞങ്ങൾ അതിൻ്റെ മൗണ്ടിംഗ് അതേ രീതിയിൽ വിവരിക്കുന്നു:

     volumeMounts:
       - mountPath: /var/log/kube-audit
         name: logs
         readOnly: false
     volumes:
     - hostPath:
         path: /var/log/kube-audit
         type: DirectoryOrCreate
       name: logs

3. audit-log-format - ഓഡിറ്റ് ലോഗ് ഫോർമാറ്റ്. സ്ഥിരസ്ഥിതിയാണ് json, എന്നാൽ ലെഗസി ടെക്സ്റ്റ് ഫോർമാറ്റും ലഭ്യമാണ് (legacy).

ഓഡിറ്റ് നയം

ഇപ്പോൾ ലോഗിംഗ് നയം വിവരിക്കുന്ന സൂചിപ്പിച്ച ഫയലിനെക്കുറിച്ച്. ഓഡിറ്റ് നയത്തിൻ്റെ ആദ്യ ആശയം level, ലോഗിംഗ് ലെവൽ. അവ ഇപ്രകാരമാണ്:

• None - ലോഗിൻ ചെയ്യരുത്;
• Metadata — ലോഗ് അഭ്യർത്ഥന മെറ്റാഡാറ്റ: ഉപയോക്താവ്, അഭ്യർത്ഥന സമയം, ടാർഗെറ്റ് റിസോഴ്സ് (പോഡ്, നെയിംസ്പേസ് മുതലായവ), പ്രവർത്തന തരം (ക്രിയ) മുതലായവ;
• Request - ലോഗ് മെറ്റാഡാറ്റയും അഭ്യർത്ഥന ബോഡിയും;
• RequestResponse - ലോഗ് മെറ്റാഡാറ്റ, അഭ്യർത്ഥന ബോഡി, പ്രതികരണ ബോഡി.

അവസാന രണ്ട് ലെവലുകൾ (Request и RequestResponse) ഉറവിടങ്ങൾ ആക്‌സസ് ചെയ്യാത്ത അഭ്യർത്ഥനകൾ ലോഗ് ചെയ്യരുത് (റിസോഴ്‌സ് ഇതര url എന്ന് വിളിക്കപ്പെടുന്ന ആക്‌സസ്സ്).

കൂടാതെ എല്ലാ അഭ്യർത്ഥനകളും കടന്നുപോകുന്നു നിരവധി ഘട്ടങ്ങൾ:

• RequestReceived - പ്രോസസറിന് അഭ്യർത്ഥന ലഭിച്ച ഘട്ടം, പ്രോസസ്സറുകളുടെ ശൃംഖലയിൽ ഇതുവരെ കൈമാറ്റം ചെയ്തിട്ടില്ല;
• ResponseStarted - പ്രതികരണ തലക്കെട്ടുകൾ അയയ്‌ക്കുന്നു, പക്ഷേ പ്രതികരണ ബോഡി അയയ്‌ക്കുന്നതിന് മുമ്പ്. ദീർഘകാല അന്വേഷണങ്ങൾക്കായി സൃഷ്ടിച്ചത് (ഉദാഹരണത്തിന്, watch);
• ResponseComplete - പ്രതികരണ ബോഡി അയച്ചു, കൂടുതൽ വിവരങ്ങളൊന്നും അയയ്ക്കില്ല;
• Panic - ഒരു അസാധാരണ സാഹചര്യം കണ്ടെത്തുമ്പോൾ സംഭവങ്ങൾ സൃഷ്ടിക്കപ്പെടുന്നു.

നിങ്ങൾക്ക് ഉപയോഗിക്കാവുന്ന ഏതെങ്കിലും ഘട്ടങ്ങൾ ഒഴിവാക്കാൻ omitStages.

ഒരു പോളിസി ഫയലിൽ, വ്യത്യസ്ത ലോഗിംഗ് ലെവലുകളുള്ള നിരവധി വിഭാഗങ്ങൾ നമുക്ക് വിവരിക്കാം. നയ വിവരണത്തിൽ കാണുന്ന ആദ്യ പൊരുത്ത നിയമം ബാധകമാകും.

api-സെർവർ കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് kubelet ഡെമൺ മാനിഫെസ്റ്റിലെ മാറ്റങ്ങൾ നിരീക്ഷിക്കുന്നു, എന്തെങ്കിലും കണ്ടെത്തിയാൽ, api-സെർവർ ഉപയോഗിച്ച് കണ്ടെയ്‌നർ പുനരാരംഭിക്കുന്നു. എന്നാൽ ഒരു പ്രധാന വിശദാംശമുണ്ട്: നയ ഫയലിലെ മാറ്റങ്ങൾ അത് അവഗണിക്കും. പോളിസി ഫയലിൽ മാറ്റങ്ങൾ വരുത്തിയ ശേഷം, നിങ്ങൾ എപിഐ-സെർവർ സ്വമേധയാ പുനരാരംഭിക്കേണ്ടതുണ്ട്. എപി-സെർവർ ഇതായി ആരംഭിച്ചതിനാൽ സ്റ്റാറ്റിക് പോഡ്, ടീം kubectl delete അത് പുനരാരംഭിക്കുന്നതിന് കാരണമാകില്ല. നിങ്ങൾ ഇത് സ്വമേധയാ ചെയ്യേണ്ടതുണ്ട് docker stop ഓഡിറ്റ് നയം മാറ്റിയ kube-masters-ൽ:

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

ഓഡിറ്റിംഗ് പ്രവർത്തനക്ഷമമാക്കുമ്പോൾ, അത് ഓർത്തിരിക്കേണ്ടത് പ്രധാനമാണ് kube-apiserver-ലെ ലോഡ് വർദ്ധിക്കുന്നു. പ്രത്യേകിച്ചും, അഭ്യർത്ഥന സന്ദർഭം സംഭരിക്കുന്നതിനുള്ള മെമ്മറി ഉപഭോഗം വർദ്ധിക്കുന്നു. പ്രതികരണ തലക്കെട്ട് അയച്ചതിനുശേഷം മാത്രമേ ലോഗിംഗ് ആരംഭിക്കൂ. ലോഡ് ഓഡിറ്റ് പോളിസി കോൺഫിഗറേഷനെ ആശ്രയിച്ചിരിക്കുന്നു.

നയങ്ങളുടെ ഉദാഹരണങ്ങൾ

ഉദാഹരണങ്ങൾ ഉപയോഗിച്ച് നയ ഫയലുകളുടെ ഘടന നോക്കാം.

ഒരു ലളിതമായ ഫയൽ ഇതാ policyലെവലിൽ എല്ലാം ലോഗ് ചെയ്യാൻ Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

നയത്തിൽ നിങ്ങൾക്ക് ഉപയോക്താക്കളുടെ ഒരു ലിസ്റ്റ് വ്യക്തമാക്കാൻ കഴിയും (Users и ServiceAccounts) കൂടാതെ ഉപയോക്തൃ ഗ്രൂപ്പുകളും. ഉദാഹരണത്തിന്, ഞങ്ങൾ സിസ്റ്റം ഉപയോക്താക്കളെ അവഗണിക്കുന്നത് ഇങ്ങനെയാണ്, എന്നാൽ മറ്റെല്ലാം ലെവലിൽ ലോഗ് ചെയ്യുക Request:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups:
      - "system:serviceaccounts"
      - "system:nodes"
    users:
      - "system:anonymous"
      - "system:apiserver"
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
  - level: Request

ലക്ഷ്യങ്ങൾ വിവരിക്കാനും കഴിയും:

• നാമമേഖലകൾ (namespaces);
• ക്രിയകൾ (ക്രിയകൾ: get, update, delete മറ്റുള്ളവരും);
• വിഭവങ്ങൾ (വിഭവങ്ങൾ, അതായത്: pod, configmaps മുതലായവ) കൂടാതെ റിസോഴ്സ് ഗ്രൂപ്പുകളും (apiGroups).

ശ്രദ്ധിക്കുക! റിസോഴ്‌സുകളും റിസോഴ്‌സ് ഗ്രൂപ്പുകളും (API ഗ്രൂപ്പുകൾ, അതായത് apiGroups), കൂടാതെ ക്ലസ്റ്ററിൽ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള അവയുടെ പതിപ്പുകളും കമാൻഡുകൾ ഉപയോഗിച്ച് ലഭിക്കും:

kubectl api-resources
kubectl api-versions

ഇനിപ്പറയുന്ന ഓഡിറ്റ് നയം മികച്ച രീതികളുടെ പ്രകടനമായി നൽകിയിരിക്കുന്നു ആലിബാബ ക്ലൗഡ് ഡോക്യുമെൻ്റേഷൻ:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Не логировать стадию RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Не логировать события, считающиеся малозначительными и не опасными:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # это api group с пустым именем, к которому относятся
                  # базовые ресурсы Kubernetes, называемые “core”
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # Не логировать обращения к read-only URLs:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Не логировать сообщения, относящиеся к типу ресурсов “события”:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Ресурсы типа Secret, ConfigMap и TokenReview могут содержать  секретные данные,
  # поэтому логируем только метаданные связанных с ними запросов
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Действия типа get, list и watch могут быть ресурсоёмкими; не логируем их
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для стандартных ресурсов API
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для всех остальных запросов
  - level: Metadata

ഓഡിറ്റ് നയത്തിൻ്റെ മറ്റൊരു നല്ല ഉദാഹരണം ജിസിഇയിൽ ഉപയോഗിച്ച പ്രൊഫൈൽ.

ഓഡിറ്റ് ഇവൻ്റുകളോട് വേഗത്തിൽ പ്രതികരിക്കാൻ, അത് സാധ്യമാണ് webhook വിവരിക്കുക. ഈ പ്രശ്നം ഉൾക്കൊള്ളുന്നു ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ, ഞാൻ അത് ഈ ലേഖനത്തിൻ്റെ പരിധിക്ക് പുറത്ത് വിടാം.

ഫലങ്ങൾ

വ്യക്തിഗതമാക്കിയ ഉപയോക്തൃ അക്കൗണ്ടുകൾ സൃഷ്‌ടിക്കാനും അവരുടെ അവകാശങ്ങൾ വേർതിരിക്കാനും അവരുടെ പ്രവർത്തനങ്ങൾ രേഖപ്പെടുത്താനും നിങ്ങളെ അനുവദിക്കുന്ന കുബർനെറ്റസ് ക്ലസ്റ്ററുകളിലെ അടിസ്ഥാന സുരക്ഷാ സംവിധാനങ്ങളുടെ ഒരു അവലോകനം ലേഖനം നൽകുന്നു. സൈദ്ധാന്തികമായോ പ്രായോഗികമായോ ഇത്തരം പ്രശ്നങ്ങൾ നേരിടുന്നവർക്ക് ഇത് ഉപയോഗപ്രദമാകുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. “പിഎസ്” ൽ നൽകിയിരിക്കുന്ന കുബർനെറ്റസിലെ സുരക്ഷ എന്ന വിഷയത്തെക്കുറിച്ചുള്ള മറ്റ് മെറ്റീരിയലുകളുടെ ലിസ്റ്റ് വായിക്കാനും ഞാൻ ശുപാർശ ചെയ്യുന്നു - അവയിൽ നിങ്ങൾക്ക് പ്രസക്തമായ പ്രശ്നങ്ങളെക്കുറിച്ച് ആവശ്യമായ വിശദാംശങ്ങൾ നിങ്ങൾ കണ്ടെത്തും.

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «33+ കുബർനെറ്റ്സ് സുരക്ഷാ ഉപകരണങ്ങൾ";
• «സെക്യൂരിറ്റി പ്രൊഫഷണലുകൾക്കായുള്ള കുബർനെറ്റസ് നെറ്റ്‌വർക്ക് നയങ്ങൾക്ക് ഒരു ആമുഖം";
• «കുബെർനെറ്റസിലെ RBAC മനസ്സിലാക്കുന്നു";
• «9 കുബർനെറ്റസ് സുരക്ഷയ്ക്കുള്ള മികച്ച സമ്പ്രദായങ്ങൾ";
• «ഒരു കുബർനെറ്റസ് ഹാക്കിന്റെ ഇരയാകാനുള്ള (അല്ല) 11 വഴികൾ".

അവലംബം: www.habr.com