ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸੁਰੱਖਿਆ ਦਾ ਏਬੀਸੀ: ਪ੍ਰਮਾਣੀਕਰਨ, ਅਧਿਕਾਰ, ਆਡਿਟਿੰਗ

ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ, ਕਿਸੇ ਵੀ ਪ੍ਰਣਾਲੀ ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ, ਸੁਰੱਖਿਆ ਦਾ ਮੁੱਦਾ ਉੱਠਦਾ ਹੈ: ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ, ਅਧਿਕਾਰਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ, ਆਡਿਟਿੰਗ ਅਤੇ ਹੋਰ ਕਾਰਜ. Kubernetes ਲਈ ਪਹਿਲਾਂ ਹੀ ਬਣਾਇਆ ਗਿਆ ਹੈ ਬਹੁਤ ਸਾਰੇ ਹੱਲ, ਜੋ ਤੁਹਾਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮੰਗ ਵਾਲੇ ਵਾਤਾਵਰਨ ਵਿੱਚ ਵੀ ਮਿਆਰਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ... ਉਹੀ ਸਮੱਗਰੀ K8s ਦੇ ਬਿਲਟ-ਇਨ ਵਿਧੀਆਂ ਦੇ ਅੰਦਰ ਲਾਗੂ ਸੁਰੱਖਿਆ ਦੇ ਬੁਨਿਆਦੀ ਪਹਿਲੂਆਂ ਨੂੰ ਸਮਰਪਿਤ ਹੈ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਉਹਨਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੋਵੇਗਾ ਜੋ ਕੁਬਰਨੇਟਸ ਨਾਲ ਜਾਣੂ ਹੋਣਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਨ - ਸੁਰੱਖਿਆ-ਸਬੰਧਤ ਮੁੱਦਿਆਂ ਦਾ ਅਧਿਐਨ ਕਰਨ ਲਈ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਵਜੋਂ.

ਪ੍ਰਮਾਣਿਕਤਾ

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਦੋ ਤਰ੍ਹਾਂ ਦੇ ਉਪਭੋਗਤਾ ਹਨ:

• ਸੇਵਾ ਖਾਤੇ — Kubernetes API ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ ਖਾਤੇ;
• ਉਪਭੋਗੀ - ਬਾਹਰੀ, ਸੁਤੰਤਰ ਸੇਵਾਵਾਂ ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ "ਆਮ" ਉਪਭੋਗਤਾ।

ਇਹਨਾਂ ਕਿਸਮਾਂ ਵਿੱਚ ਮੁੱਖ ਅੰਤਰ ਇਹ ਹੈ ਕਿ ਸੇਵਾ ਖਾਤਿਆਂ ਲਈ ਕੁਬਰਨੇਟਸ API ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਵਸਤੂਆਂ ਹਨ (ਉਹਨਾਂ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ - ServiceAccounts), ਜੋ ਕਿ ਇੱਕ ਨੇਮਸਪੇਸ ਨਾਲ ਬੰਨ੍ਹੇ ਹੋਏ ਹਨ ਅਤੇ ਸੀਕਰੇਟਸ ਕਿਸਮ ਦੀਆਂ ਵਸਤੂਆਂ ਵਿੱਚ ਕਲੱਸਟਰ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਡੇਟਾ ਦੇ ਇੱਕ ਸੈੱਟ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ। ਅਜਿਹੇ ਉਪਭੋਗਤਾ (ਸੇਵਾ ਖਾਤੇ) ਮੁੱਖ ਤੌਰ 'ਤੇ Kubernetes ਕਲੱਸਟਰ ਵਿੱਚ ਚੱਲ ਰਹੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ Kubernetes API ਤੱਕ ਪਹੁੰਚ ਅਧਿਕਾਰਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਹੁੰਦੇ ਹਨ।

ਆਮ ਉਪਭੋਗਤਾਵਾਂ ਕੋਲ ਕੁਬਰਨੇਟਸ API ਵਿੱਚ ਐਂਟਰੀਆਂ ਨਹੀਂ ਹਨ: ਉਹਨਾਂ ਨੂੰ ਬਾਹਰੀ ਵਿਧੀਆਂ ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹ ਕਲੱਸਟਰ ਤੋਂ ਬਾਹਰ ਰਹਿਣ ਵਾਲੇ ਲੋਕਾਂ ਜਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ।

ਹਰੇਕ API ਬੇਨਤੀ ਜਾਂ ਤਾਂ ਇੱਕ ਸੇਵਾ ਖਾਤੇ, ਇੱਕ ਉਪਭੋਗਤਾ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਅਗਿਆਤ ਮੰਨੀ ਜਾਂਦੀ ਹੈ।

ਉਪਭੋਗਤਾ ਪ੍ਰਮਾਣੀਕਰਨ ਡੇਟਾ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

• ਉਪਭੋਗੀ - ਉਪਭੋਗਤਾ ਨਾਮ (ਕੇਸ ਸੰਵੇਦਨਸ਼ੀਲ!);
• UID - ਇੱਕ ਮਸ਼ੀਨ-ਪੜ੍ਹਨਯੋਗ ਉਪਭੋਗਤਾ ਪਛਾਣ ਸਤਰ ਜੋ "ਉਪਭੋਗਤਾ ਨਾਮ ਨਾਲੋਂ ਵਧੇਰੇ ਇਕਸਾਰ ਅਤੇ ਵਿਲੱਖਣ" ਹੈ;
• ਗਰੁੱਪ — ਸਮੂਹਾਂ ਦੀ ਸੂਚੀ ਜਿਸ ਨਾਲ ਉਪਭੋਗਤਾ ਸਬੰਧਤ ਹੈ;
• ਵਾਧੂ — ਵਾਧੂ ਖੇਤਰ ਜੋ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿਧੀ ਦੁਆਰਾ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਕੁਬਰਨੇਟਸ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ: 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 ਕੁੰਜੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨਾ, ਇੱਕ ਉਪਭੋਗਤਾ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਾਪਤ ਕਰਨਾ (ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇੱਕ ਖਾਤਾ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਕੋਲ 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 ਕਲੱਸਟਰ ਦੇ ਏਪੀਆਈ-ਸਰਵਰ ਦੀ ਸ਼ੁੱਧਤਾ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰੇਗਾ):

    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, i.e. ਪ੍ਰਾਪਤ ਕੀਤਾ certificate-authority-data ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ

kubeadm ਨਾਲ ਸਰਟੀਫਿਕੇਟ

ਰਿਲੀਜ਼ ਦੇ ਨਾਲ ਕੁਬਰਨੇਟਸ 1.15..XNUMX ਵਿੱਚ ਇਸਦੇ ਸਮਰਥਨ ਦੇ ਅਲਫ਼ਾ ਸੰਸਕਰਣ ਦੇ ਕਾਰਨ ਸਰਟੀਫਿਕੇਟਾਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਹੋ ਗਿਆ ਹੈ 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.

ਡੂੰਘੇ ਖੋਦਣ

ਉਹਨਾਂ ਲਈ ਜੋ ਹੋਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਣਿਤ ਮੁੱਦਿਆਂ ਨੂੰ ਸਮਝਣਾ ਚਾਹੁੰਦੇ ਹਨ:

• ਵੱਖਰਾ ਲੇਖ ਅਧਿਕਾਰਤ ਕੁਬਰਨੇਟਸ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟਾਂ ਨਾਲ ਕੰਮ ਕਰਨ 'ਤੇ;
• ਬਿਟਨਾਮੀ ਤੋਂ ਵਧੀਆ ਲੇਖ, ਜਿਸ ਵਿੱਚ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੇ ਮੁੱਦੇ ਨੂੰ ਵਿਹਾਰਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਛੂਹਿਆ ਗਿਆ ਹੈ।
• ਆਮ ਦਸਤਾਵੇਜ਼ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਪ੍ਰਮਾਣਿਕਤਾ 'ਤੇ.

ਪ੍ਰਮਾਣੀਕਰਣ

ਡਿਫੌਲਟ ਅਧਿਕਾਰਤ ਖਾਤੇ ਕੋਲ ਕਲੱਸਟਰ 'ਤੇ ਕੰਮ ਕਰਨ ਦੇ ਅਧਿਕਾਰ ਨਹੀਂ ਹਨ। ਅਨੁਮਤੀਆਂ ਦੇਣ ਲਈ, ਕੁਬਰਨੇਟਸ ਇੱਕ ਪ੍ਰਮਾਣੀਕਰਨ ਵਿਧੀ ਲਾਗੂ ਕਰਦਾ ਹੈ।

ਸੰਸਕਰਣ 1.6 ਤੋਂ ਪਹਿਲਾਂ, ਕੁਬਰਨੇਟਸ ਨਾਮਕ ਇੱਕ ਪ੍ਰਮਾਣਿਕਤਾ ਕਿਸਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਨ ਏ.ਬੀ.ਏ.ਸੀ (ਵਿਸ਼ੇਸ਼ਤਾ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਨਿਯੰਤਰਣ)। ਇਸ ਬਾਰੇ ਵੇਰਵੇ ਵਿੱਚ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼. ਇਸ ਪਹੁੰਚ ਨੂੰ ਵਰਤਮਾਨ ਵਿੱਚ ਵਿਰਾਸਤ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਅਜੇ ਵੀ ਇਸਨੂੰ ਹੋਰ ਪ੍ਰਮਾਣੀਕਰਨ ਕਿਸਮਾਂ ਦੇ ਨਾਲ ਵਰਤ ਸਕਦੇ ਹੋ।

ਕਲੱਸਟਰ ਤੱਕ ਪਹੁੰਚ ਅਧਿਕਾਰਾਂ ਨੂੰ ਵੰਡਣ ਦੇ ਮੌਜੂਦਾ (ਅਤੇ ਵਧੇਰੇ ਲਚਕਦਾਰ) ਤਰੀਕੇ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਆਰ.ਬੀ.ਏ.ਸੀ. (ਭੂਮਿਕਾ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਨਿਯੰਤਰਣ). ਇਸ ਨੂੰ ਸੰਸਕਰਣ ਤੋਂ ਸਥਿਰ ਘੋਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਕੁਬਰਨੇਟਸ 1.8..XNUMX. RBAC ਇੱਕ ਰਾਈਟਸ ਮਾਡਲ ਲਾਗੂ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਹਰ ਉਹ ਚੀਜ਼ ਜਿਸਦੀ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ, ਵਰਜਿਤ ਹੈ।
RBAC ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਪੈਰਾਮੀਟਰ ਨਾਲ ਕੁਬਰਨੇਟਸ ਏਪੀਆਈ-ਸਰਵਰ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ --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 ਦਸਤਾਵੇਜ਼.

ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਹੀ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਸਾਰੇ ਮਾਪਦੰਡ api-ਸਰਵਰ ਸੰਰਚਨਾ ਨਾਲ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਸੈੱਟ ਕੀਤੇ ਗਏ ਹਨ (ਮੂਲ ਰੂਪ ਵਿੱਚ /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.

ਇੱਕ ਪਾਲਿਸੀ ਫਾਈਲ ਵਿੱਚ, ਅਸੀਂ ਵੱਖ-ਵੱਖ ਲੌਗਿੰਗ ਪੱਧਰਾਂ ਵਾਲੇ ਕਈ ਭਾਗਾਂ ਦਾ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹਾਂ। ਨੀਤੀ ਦੇ ਵਰਣਨ ਵਿੱਚ ਪਾਇਆ ਗਿਆ ਪਹਿਲਾ ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ।

ਕੁਬੇਲੇਟ ਡੈਮਨ api-ਸਰਵਰ ਸੰਰਚਨਾ ਦੇ ਨਾਲ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ ਅਤੇ, ਜੇਕਰ ਕੋਈ ਖੋਜਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ 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

ਆਡਿਟ ਨੀਤੀ ਦਾ ਇੱਕ ਹੋਰ ਵਧੀਆ ਉਦਾਹਰਣ ਹੈ ਪ੍ਰੋਫਾਈਲ GCE ਵਿੱਚ ਵਰਤੀ ਜਾਂਦੀ ਹੈ.

ਆਡਿਟ ਇਵੈਂਟਾਂ ਦਾ ਤੁਰੰਤ ਜਵਾਬ ਦੇਣ ਲਈ, ਇਹ ਸੰਭਵ ਹੈ ਵੈਬਹੁੱਕ ਦਾ ਵਰਣਨ ਕਰੋ. ਇਸ ਮੁੱਦੇ ਨੂੰ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼, ਮੈਂ ਇਸਨੂੰ ਇਸ ਲੇਖ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਛੱਡਾਂਗਾ।

ਨਤੀਜੇ

ਲੇਖ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਵਿਧੀਆਂ ਦੀ ਇੱਕ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਵਿਅਕਤੀਗਤ ਉਪਭੋਗਤਾ ਖਾਤੇ ਬਣਾਉਣ, ਉਹਨਾਂ ਦੇ ਅਧਿਕਾਰਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਹ ਉਹਨਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੋਵੇਗਾ ਜੋ ਸਿਧਾਂਤ ਜਾਂ ਅਭਿਆਸ ਵਿੱਚ ਅਜਿਹੇ ਮੁੱਦਿਆਂ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਹੇ ਹਨ. ਮੈਂ ਇਹ ਵੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸੁਰੱਖਿਆ ਦੇ ਵਿਸ਼ੇ 'ਤੇ ਹੋਰ ਸਮੱਗਰੀਆਂ ਦੀ ਸੂਚੀ ਪੜ੍ਹੋ, ਜੋ ਕਿ "PS" ਵਿੱਚ ਦਿੱਤੀ ਗਈ ਹੈ - ਸ਼ਾਇਦ ਉਹਨਾਂ ਵਿੱਚੋਂ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਲੋੜੀਂਦੇ ਵੇਰਵੇ ਮਿਲ ਜਾਣਗੇ ਜੋ ਤੁਹਾਡੇ ਲਈ ਢੁਕਵੀਆਂ ਹਨ।

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «33+ ਕੁਬਰਨੇਟਸ ਸੁਰੱਖਿਆ ਟੂਲ";
• «ਸੁਰੱਖਿਆ ਪੇਸ਼ੇਵਰਾਂ ਲਈ ਕੁਬਰਨੇਟਸ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਦੀ ਜਾਣ-ਪਛਾਣ";
• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਆਰਬੀਏਸੀ ਨੂੰ ਸਮਝਣਾ";
• «ਕੁਬਰਨੇਟਸ ਸੁਰੱਖਿਆ ਲਈ 9 ਵਧੀਆ ਅਭਿਆਸ";
• «ਕੁਬਰਨੇਟਸ ਹੈਕ ਦਾ ਸ਼ਿਕਾਰ ਹੋਣ (ਨਾ) ਦੇ 11 ਤਰੀਕੇ".

ਸਰੋਤ: www.habr.com