કુબરનેટ્સમાં સુરક્ષાનું એબીસી: પ્રમાણીકરણ, અધિકૃતતા, ઓડિટીંગ

વહેલા અથવા પછીના સમયમાં, કોઈપણ સિસ્ટમના સંચાલનમાં, સુરક્ષાનો મુદ્દો ઉભો થાય છે: પ્રમાણીકરણ, અધિકારોનું વિભાજન, ઑડિટિંગ અને અન્ય કાર્યોની ખાતરી કરવી. Kubernetes માટે પહેલેથી જ બનાવેલ છે ઘણા ઉકેલો, જે તમને ખૂબ જ માંગવાળા વાતાવરણમાં પણ ધોરણોનું પાલન કરવાની મંજૂરી આપે છે... સમાન સામગ્રી K8s ની બિલ્ટ-ઇન મિકેનિઝમ્સમાં લાગુ સુરક્ષાના મૂળભૂત પાસાઓને સમર્પિત છે. સૌ પ્રથમ, તે એવા લોકો માટે ઉપયોગી થશે કે જેઓ કુબરનેટ્સ સાથે પરિચિત થવાનું શરૂ કરી રહ્યા છે - સુરક્ષા-સંબંધિત મુદ્દાઓનો અભ્યાસ કરવા માટેના પ્રારંભિક બિંદુ તરીકે.

પ્રમાણીકરણ

કુબરનેટ્સમાં બે પ્રકારના વપરાશકર્તાઓ છે:

• સેવા એકાઉન્ટ્સ - કુબરનેટ્સ API દ્વારા સંચાલિત એકાઉન્ટ્સ;
• વપરાશકર્તાઓ - "સામાન્ય" વપરાશકર્તાઓ બાહ્ય, સ્વતંત્ર સેવાઓ દ્વારા સંચાલિત.

આ પ્રકારો વચ્ચેનો મુખ્ય તફાવત એ છે કે સર્વિસ એકાઉન્ટ્સ માટે કુબરનેટ્સ API માં વિશિષ્ટ ઑબ્જેક્ટ્સ છે (તેને કહેવામાં આવે છે - ServiceAccounts), જે નેમસ્પેસ સાથે જોડાયેલ છે અને સિક્રેટ્સ પ્રકારના ઑબ્જેક્ટ્સમાં ક્લસ્ટરમાં સંગ્રહિત અધિકૃત ડેટાના સમૂહ સાથે જોડાયેલ છે. આવા વપરાશકર્તાઓ (સર્વિસ એકાઉન્ટ્સ) મુખ્યત્વે કુબરનેટ્સ ક્લસ્ટરમાં ચાલતી પ્રક્રિયાઓના કુબરનેટ્સ API ના ઍક્સેસ અધિકારોનું સંચાલન કરવાનો છે.

સામાન્ય વપરાશકર્તાઓ પાસે કુબરનેટ્સ API માં એન્ટ્રીઓ હોતી નથી: તેઓ બાહ્ય મિકેનિઝમ્સ દ્વારા સંચાલિત હોવા જોઈએ. તેઓ ક્લસ્ટરની બહાર રહેતા લોકો અથવા પ્રક્રિયાઓ માટે બનાવાયેલ છે.

દરેક API વિનંતી કાં તો સેવા ખાતા, વપરાશકર્તા સાથે સંકળાયેલ છે અથવા અનામી ગણવામાં આવે છે.

વપરાશકર્તા પ્રમાણીકરણ ડેટામાં શામેલ છે:

• વપરાશકર્તા નામ — વપરાશકર્તા નામ (કેસ સેન્સિટિવ!);
• યુ.આઇ.ડી. - મશીન દ્વારા વાંચી શકાય તેવી વપરાશકર્તા ઓળખ સ્ટ્રિંગ કે જે "વપરાશકર્તાનામ કરતાં વધુ સુસંગત અને અનન્ય" છે;
• જૂથો — જૂથોની સૂચિ કે જેનો વપરાશકર્તા સંબંધ ધરાવે છે;
• વિશેષ — વધારાના ક્ષેત્રો કે જેનો ઉપયોગ અધિકૃતતા પદ્ધતિ દ્વારા કરી શકાય છે.

કુબરનેટ્સ મોટી સંખ્યામાં પ્રમાણીકરણ પદ્ધતિઓનો ઉપયોગ કરી શકે છે: 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"

• કુબરનેટ્સ ક્લસ્ટર CA કીનો ઉપયોગ કરીને પ્રમાણપત્ર વિનંતી પર પ્રક્રિયા કરવી, વપરાશકર્તા પ્રમાણપત્ર મેળવવું (પ્રમાણપત્ર મેળવવા માટે, તમારે એવા એકાઉન્ટનો ઉપયોગ કરવો આવશ્યક છે કે જેની પાસે કુબરનેટ્સ ક્લસ્ટર 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-server રૂપરેખામાં શોધી શકાય છે, જે મૂળભૂત રીતે સ્થિત છે /etc/kubernetes/manifests/kube-apiserver.yaml.

પરિણામી રૂપરેખા stdout માં આઉટપુટ થશે. તે માં સાચવવાની જરૂર છે ~/.kube/config વપરાશકર્તા ખાતું અથવા પર્યાવરણ વેરીએબલમાં ઉલ્લેખિત ફાઇલમાં KUBECONFIG.

વધુ ઊંડા ખોદવું

જેઓ વધુ સારી રીતે વર્ણવેલ મુદ્દાઓને સમજવા માંગે છે તેમના માટે:

• અલગ લેખ સત્તાવાર કુબરનેટ્સ દસ્તાવેજોમાં પ્રમાણપત્રો સાથે કામ કરવા પર;
• બિટનામી તરફથી સારો લેખ, જેમાં પ્રમાણપત્રોના મુદ્દાને વ્યવહારિક દ્રષ્ટિકોણથી સ્પર્શવામાં આવે છે.
• સામાન્ય દસ્તાવેજીકરણ કુબરનેટ્સમાં પ્રમાણીકરણ પર.

અધિકૃતતા

ડિફૉલ્ટ અધિકૃત એકાઉન્ટ પાસે ક્લસ્ટર પર કામ કરવાના અધિકારો નથી. પરવાનગીઓ આપવા માટે, Kubernetes એક અધિકૃતતા પદ્ધતિ લાગુ કરે છે.

સંસ્કરણ 1.6 પહેલા, કુબરનેટ્સ નામના અધિકૃત પ્રકારનો ઉપયોગ કરતા હતા ABAC (એટ્રીબ્યુટ આધારિત એક્સેસ કંટ્રોલ). તેના વિશેની વિગતો તેમાં મળી શકે છે સત્તાવાર દસ્તાવેજીકરણ. આ અભિગમ હાલમાં લેગસી માનવામાં આવે છે, પરંતુ તમે હજુ પણ અન્ય પ્રમાણીકરણ પ્રકારો સાથે તેનો ઉપયોગ કરી શકો છો.

ક્લસ્ટરના ઍક્સેસ અધિકારોને વિભાજિત કરવાની વર્તમાન (અને વધુ લવચીક) રીત કહેવામાં આવે છે આરબીએસી (ભૂમિકા-આધારિત ઍક્સેસ નિયંત્રણ). સંસ્કરણથી તેને સ્થિર જાહેર કરવામાં આવ્યું છે કુબર્નીટ્સ 1.8. RBAC એક રાઇટ્સ મોડલ અમલમાં મૂકે છે જેમાં સ્પષ્ટપણે પરવાનગી ન હોય તેવી દરેક વસ્તુ પ્રતિબંધિત છે.
RBAC ને સક્ષમ કરવા માટે, તમારે પેરામીટર સાથે Kubernetes api-server શરૂ કરવાની જરૂર છે --authorization-mode=RBAC. પરિમાણો એપીઆઈ-સર્વર રૂપરેખાંકન સાથે મેનિફેસ્ટમાં સેટ કરેલ છે, જે મૂળભૂત રીતે પાથ સાથે સ્થિત છે /etc/kubernetes/manifests/kube-apiserver.yaml, વિભાગમાં command. જો કે, RBAC પહેલેથી જ ડિફૉલ્ટ રૂપે સક્ષમ છે, તેથી સંભવતઃ તમારે તેના વિશે ચિંતા ન કરવી જોઈએ: તમે આને મૂલ્ય દ્વારા ચકાસી શકો છો authorization-mode (પહેલાથી જ ઉલ્લેખ કર્યો છે kube-apiserver.yaml). માર્ગ દ્વારા, તેના અર્થોમાં અન્ય પ્રકારની અધિકૃતતા હોઈ શકે છે (node, webhook, always allow), પરંતુ અમે તેમની વિચારણાને સામગ્રીના અવકાશની બહાર છોડીશું.

માર્ગ દ્વારા, અમે પહેલેથી જ પ્રકાશિત કર્યું છે એક લેખ RBAC સાથે કામ કરવાના સિદ્ધાંતો અને વિશેષતાઓના એકદમ વિગતવાર વર્ણન સાથે, તેથી આગળ હું મારી જાતને મૂળભૂત બાબતો અને ઉદાહરણોની સંક્ષિપ્ત સૂચિ સુધી મર્યાદિત કરીશ.

નીચેની API એકમોનો ઉપયોગ RBAC મારફત કુબરનેટ્સમાં ઍક્સેસને નિયંત્રિત કરવા માટે થાય છે:

• Role и ClusterRole - ભૂમિકાઓ જે ઍક્સેસ અધિકારોનું વર્ણન કરે છે:
• Role તમને નેમસ્પેસમાં અધિકારોનું વર્ણન કરવાની મંજૂરી આપે છે;
• ClusterRole - ક્લસ્ટરની અંદર, ક્લસ્ટર-વિશિષ્ટ ઑબ્જેક્ટ્સ જેમ કે નોડ્સ, બિન-સંસાધન url (એટલે ​​​​કે કુબરનેટ્સ સંસાધનોથી સંબંધિત નથી - ઉદાહરણ તરીકે, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - બંધન માટે વપરાય છે Role и 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 API માં તમામ કૉલ્સને લૉગ કરવાની મંજૂરી આપે છે. જેમ તમે અનુમાન કરી શકો છો, ક્લસ્ટરની સ્થિતિનું નિરીક્ષણ કરવા અને બદલવાથી સંબંધિત તમામ ક્રિયાઓ આ API દ્વારા કરવામાં આવે છે. તેની ક્ષમતાઓનું સારું વર્ણન (હંમેશની જેમ) માં મળી શકે છે સત્તાવાર દસ્તાવેજીકરણ K8s. આગળ, હું વિષયને સરળ ભાષામાં રજૂ કરવાનો પ્રયાસ કરીશ.

અને તેથી, ઓડિટીંગ સક્ષમ કરવા માટે, અમારે એપીઆઈ-સર્વરમાં કન્ટેનરમાં ત્રણ જરૂરી પરિમાણો પસાર કરવાની જરૂર છે, જે નીચે વધુ વિગતવાર વર્ણવેલ છે:

• --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 દસ્તાવેજીકરણ.

પહેલેથી જ ઉલ્લેખ કર્યો છે તેમ, તમામ પરિમાણો એપીઆઈ-સર્વર ગોઠવણી સાથે મેનિફેસ્ટમાં સેટ કરેલ છે (ડિફૉલ્ટ રૂપે /etc/kubernetes/manifests/kube-apiserver.yaml), વિભાગમાં command. ચાલો 3 જરૂરી પરિમાણો પર પાછા જઈએ અને તેનું વિશ્લેષણ કરીએ:

1. audit-policy-file — ઓડિટ નીતિનું વર્ણન કરતી YAML ફાઇલનો પાથ. અમે પછીથી તેના સમાવિષ્ટો પર પાછા આવીશું, પરંતુ હમણાં માટે હું નોંધ કરીશ કે ફાઇલ એપીઆઈ-સર્વર પ્રક્રિયા દ્વારા વાંચી શકાય તેવી હોવી જોઈએ. તેથી, તેને કન્ટેનરની અંદર માઉન્ટ કરવું જરૂરી છે, જેના માટે તમે નીચેના કોડને રૂપરેખાના યોગ્ય વિભાગોમાં ઉમેરી શકો છો:

     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.

પોલિસી ફાઇલમાં, અમે વિવિધ લોગીંગ સ્તરો સાથે કેટલાક વિભાગોનું વર્ણન કરી શકીએ છીએ. પૉલિસી વર્ણનમાં જોવા મળેલો પ્રથમ મેચિંગ નિયમ લાગુ કરવામાં આવશે.

કુબેલેટ ડિમન એપીઆઈ-સર્વર રૂપરેખાંકન સાથે મેનિફેસ્ટમાં ફેરફારોનું નિરીક્ષણ કરે છે અને, જો કોઈ શોધાયેલ હોય, તો એપીઆઈ-સર્વર સાથે કન્ટેનરને પુનઃપ્રારંભ કરે છે. પરંતુ એક મહત્વપૂર્ણ વિગત છે: પોલિસી ફાઇલમાં ફેરફારો તેના દ્વારા અવગણવામાં આવશે. પોલિસી ફાઇલમાં ફેરફારો કર્યા પછી, તમારે એપીઆઈ-સર્વરને મેન્યુઅલી રીસ્ટાર્ટ કરવાની જરૂર પડશે. એપીઆઈ-સર્વર તરીકે શરૂ થયું હોવાથી સ્થિર પોડ, ટીમ kubectl delete તેને પુનઃપ્રારંભ કરશે નહીં. તમારે તેને મેન્યુઅલી કરવું પડશે docker stop kube-masters પર, જ્યાં ઓડિટ નીતિ બદલાઈ છે:

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

ઑડિટિંગને સક્ષમ કરતી વખતે, તે યાદ રાખવું મહત્વપૂર્ણ છે કુબે-એપીસર્વર પરનો ભાર વધે છે. ખાસ કરીને, વિનંતી સંદર્ભ સ્ટોર કરવા માટે મેમરી વપરાશ વધે છે. પ્રતિભાવ હેડર મોકલ્યા પછી જ લોગીંગ શરૂ થાય છે. લોડ પણ ઓડિટ નીતિ રૂપરેખાંકન પર આધાર રાખે છે.

નીતિઓના ઉદાહરણો

ચાલો ઉદાહરણોનો ઉપયોગ કરીને પોલિસી ફાઇલોની રચના જોઈએ.

અહીં એક સરળ ફાઇલ છે 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

ઓડિટ નીતિનું બીજું સારું ઉદાહરણ છે GCE માં વપરાયેલ પ્રોફાઇલ.

ઑડિટ ઇવેન્ટ્સને ઝડપથી જવાબ આપવા માટે, તે શક્ય છે વેબહૂકનું વર્ણન કરો. આ મુદ્દો આવરી લેવામાં આવ્યો છે સત્તાવાર દસ્તાવેજીકરણ, હું તેને આ લેખના અવકાશની બહાર છોડીશ.

પરિણામો

આ લેખ કુબરનેટ્સ ક્લસ્ટર્સમાં મૂળભૂત સુરક્ષા પદ્ધતિઓનું વિહંગાવલોકન પ્રદાન કરે છે, જે તમને વ્યક્તિગત વપરાશકર્તા એકાઉન્ટ્સ બનાવવા, તેમના અધિકારોને અલગ કરવા અને તેમની ક્રિયાઓ રેકોર્ડ કરવાની મંજૂરી આપે છે. હું આશા રાખું છું કે જેઓ સિદ્ધાંતમાં અથવા વ્યવહારમાં આવી સમસ્યાઓનો સામનો કરી રહ્યા છે તેમના માટે તે ઉપયોગી થશે. હું એ પણ ભલામણ કરું છું કે તમે કુબરનેટ્સમાં સુરક્ષાના વિષય પરની અન્ય સામગ્રીઓની સૂચિ વાંચો, જે "PS" માં આપવામાં આવી છે - કદાચ તેમાંથી તમને સંબંધિત સમસ્યાઓ પર જરૂરી વિગતો મળશે.

PS

અમારા બ્લોગ પર પણ વાંચો:

• «33+ કુબરનેટ્સ સુરક્ષા સાધનો»;
• «સુરક્ષા વ્યાવસાયિકો માટે કુબરનેટ્સ નેટવર્ક નીતિઓનો પરિચય»;
• «કુબરનેટ્સમાં RBAC ને સમજવું»;
• «કુબરનેટ્સ સુરક્ષા માટે 9 શ્રેષ્ઠ પ્રયાસો»;
• «કુબરનેટ્સ હેકનો શિકાર બનવાની (નહીં) 11 રીતો».

સોર્સ: www.habr.com