🥇Kubernetes 보안의 ABC: 인증, 권한 부여, 감사

조만간 시스템 운영 중에 인증 보장, 권한 분리, 감사 및 기타 작업과 같은 보안 문제가 발생합니다. Kubernetes용으로 이미 생성됨 많은 솔루션이를 통해 매우 까다로운 환경에서도 표준을 준수할 수 있습니다. K8s의 내장 메커니즘 내에서 구현되는 보안의 기본 측면에 대해서도 동일한 자료가 제공됩니다. 우선, 보안 관련 문제를 연구하기 위한 출발점으로 Kubernetes에 익숙해지기 시작하는 사람들에게 유용할 것입니다.

인증

Kubernetes에는 두 가지 유형의 사용자가 있습니다.

서비스 계정 — Kubernetes API로 관리되는 계정
사용자 — 외부의 독립적인 서비스에 의해 관리되는 "일반" 사용자입니다.

이러한 유형 간의 주요 차이점은 서비스 계정의 경우 Kubernetes API에 특수 개체가 있다는 것입니다(이를 다음과 같이 호출함). ServiceAccounts)은 Secrets 유형의 객체로 클러스터에 저장된 인증 데이터 세트와 네임스페이스에 연결되어 있습니다. 이러한 사용자(서비스 계정)는 주로 Kubernetes 클러스터에서 실행되는 프로세스의 Kubernetes API에 대한 액세스 권한을 관리하기 위한 것입니다.

일반 사용자는 Kubernetes API에 항목이 없으며 외부 메커니즘을 통해 관리되어야 합니다. 클러스터 외부에 거주하는 사람이나 프로세스를 위한 것입니다.

각 API 요청은 서비스 계정, 사용자와 연결되거나 익명으로 간주됩니다.

사용자 인증 데이터에는 다음이 포함됩니다.

ID / Username — 사용자 이름(대소문자 구분!);
UID - "사용자 이름보다 더 일관되고 고유한" 기계 판독 가능한 사용자 식별 문자열
그룹 — 사용자가 속한 그룹 목록
여분의 — 인증 메커니즘에서 사용할 수 있는 추가 필드입니다.

Kubernetes는 X509 인증서, Bearer 토큰, 인증 프록시, HTTP 기본 인증 등 다양한 인증 메커니즘을 사용할 수 있습니다. 이러한 메커니즘을 사용하면 비밀번호가 포함된 정적 파일부터 OpenID OAuth2까지 다양한 인증 체계를 구현할 수 있습니다.

또한 여러 인증 체계를 동시에 사용할 수도 있습니다. 기본적으로 클러스터는 다음을 사용합니다.

서비스 계정 토큰 - 서비스 계정용
X509 - 사용자용.

ServiceAccounts 관리에 대한 질문은 이 문서의 범위를 벗어납니다. 하지만 이 문제에 대해 더 자세히 알아보고 싶은 분들은 다음으로 시작하는 것이 좋습니다. 공식 문서 페이지. 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

이렇게 하려면 base64를 사용하여 지정된 파일을 인코딩하고 구성에 등록한 다음 키 이름에 접미사를 추가하면 됩니다. -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 문서의 인증서 작업에 대해
비트나미의 좋은 글, 인증서 발급을 실용적인 관점에서 다루고 있습니다.
일반 문서 Kubernetes의 인증에 대해

권한 부여

기본 인증 계정에는 클러스터에서 작동할 수 있는 권한이 없습니다. 권한을 부여하기 위해 Kubernetes는 권한 부여 메커니즘을 구현합니다.

버전 1.6 이전에는 Kubernetes가 다음과 같은 인증 유형을 사용했습니다. ABAC (속성 기반 액세스 제어). 이에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 공식 문서. 이 접근 방식은 현재 레거시로 간주되지만 다른 인증 유형과 함께 계속 사용할 수 있습니다.

클러스터에 대한 액세스 권한을 분할하는 현재의 (그리고 더 유연한) 방법은 다음과 같습니다. RBAC (역할 기반 액세스 제어). 버전 이후 안정적으로 선언되었습니다. 쿠버네티스 1.8. RBAC는 명시적으로 허용되지 않은 모든 것을 금지하는 권리 모델을 구현합니다.
RBAC를 활성화하려면, 매개변수를 사용하여 Kubernetes API 서버를 시작해야 합니다. --authorization-mode=RBAC. 매개변수는 기본적으로 경로를 따라 위치하는 api-server 구성을 사용하여 매니페스트에 설정됩니다. /etc/kubernetes/manifests/kube-apiserver.yaml, 섹션에서 command. 그러나 RBAC는 이미 기본적으로 활성화되어 있으므로 걱정할 필요가 없습니다. 값으로 이를 확인할 수 있습니다. authorization-mode (이미 언급한 부분에서 kube-apiserver.yaml). 그건 그렇고, 그 의미 중에는 다른 유형의 인증이 있을 수 있습니다(node, webhook, always allow) 그러나 이에 대한 고려는 자료의 범위를 벗어나도록 하겠습니다.

그건 그렇고, 우리는 이미 출판했습니다 статью RBAC 작업의 원리와 기능에 대해 상당히 자세히 설명했기 때문에 더 나아가 기본 사항과 예에 대한 간략한 목록으로 제한하겠습니다.

다음 API 엔터티는 RBAC를 통해 Kubernetes의 액세스를 제어하는 데 사용됩니다.

Role и ClusterRole — 액세스 권한을 설명하는 역할:
Role 네임스페이스 내의 권리를 설명할 수 있습니다.
ClusterRole - 노드, 비리소스 URL(즉, Kubernetes 리소스와 관련되지 않은 URL)과 같은 클러스터별 개체를 포함하여 클러스터 내 - 예: /version, /logs, /api*);
RoleBinding и ClusterRoleBinding - 바인딩에 사용 Role и ClusterRole 사용자, 사용자 그룹 또는 ServiceAccount에.

Role 및 RoleBinding 엔터티는 네임스페이스에 의해 제한됩니다. 동일한 네임스페이스 내에 있어야 합니다. 그러나 RoleBinding은 ClusterRole을 참조할 수 있으며 이를 통해 일반 권한 집합을 생성하고 이를 사용하여 액세스를 제어할 수 있습니다.

역할은 다음을 포함하는 규칙 세트를 사용하여 권한을 설명합니다.

API 그룹 - 참조 공식 문서 apiGroups 및 출력별 kubectl api-resources;
자원 (자원: pod, namespace, deployment 등등.);
동사(동사: set, update 등).
리소스 이름(resourceNames) - 이 유형의 모든 리소스가 아닌 특정 리소스에 대한 액세스를 제공해야 하는 경우입니다.

Kubernetes의 권한 부여에 대한 더 자세한 분석은 페이지에서 확인할 수 있습니다. 공식 문서. 대신에(또는 이에 추가하여) 그녀의 작업을 설명하는 예를 제시하겠습니다.

RBAC 엔터티의 예

단순한 Role, Pod의 목록과 상태를 가져오고 네임스페이스에서 모니터링할 수 있습니다. 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, Pod의 목록과 상태를 가져오고 클러스터 전체에서 모니터링할 수 있습니다.

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

예 RoleBinding, 이는 사용자가 mynewuser 네임스페이스의 "읽기" Pod 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

이벤트 감사

개략적으로 Kubernetes 아키텍처는 다음과 같이 표현될 수 있습니다.

요청 처리를 담당하는 핵심 Kubernetes 구성 요소는 다음과 같습니다. API 서버. 클러스터의 모든 작업이 이를 통과합니다. "라는 기사에서 이러한 내부 메커니즘에 대해 자세히 알아볼 수 있습니다.kubectl run을 실행하면 Kubernetes에서는 어떤 일이 발생하나요?".

시스템 감사는 기본적으로 비활성화되어 있는 Kubernetes의 흥미로운 기능입니다. Kubernetes API에 대한 모든 호출을 기록할 수 있습니다. 짐작할 수 있듯이 클러스터 상태 모니터링 및 변경과 관련된 모든 작업은 이 API를 통해 수행됩니다. 그 기능에 대한 좋은 설명은 (평소와 같이) 다음에서 찾을 수 있습니다. 공식 문서 K8s. 다음에는 좀 더 간단한 언어로 주제를 제시해 보겠습니다.

따라서, 감사를 활성화하려면, 아래에 자세히 설명된 세 가지 필수 매개변수를 api-server의 컨테이너에 전달해야 합니다.

--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-server 구성을 사용하여 매니페스트에 설정됩니다(기본적으로 /etc/kubernetes/manifests/kube-apiserver.yaml) 섹션에서 command. 3가지 필수 매개변수로 돌아가서 분석해 보겠습니다.

audit-policy-file — 감사 정책을 설명하는 YAML 파일의 경로입니다. 나중에 그 내용으로 돌아가겠지만 지금은 api-server 프로세스에서 파일을 읽을 수 있어야 한다는 점에 유의하겠습니다. 따라서 컨테이너 내부에 마운트해야 하며, 이를 위해 구성의 적절한 섹션에 다음 코드를 추가할 수 있습니다.
```
  volumeMounts:
    - mountPath: /etc/kubernetes/policies
      name: policies
      readOnly: true
  volumes:
  - hostPath:
      path: /etc/kubernetes/policies
      type: DirectoryOrCreate
    name: policies
```

audit-log-path — 로그 파일의 경로입니다. 경로는 api-server 프로세스에서도 액세스할 수 있어야 하므로 동일한 방식으로 마운트를 설명합니다.

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

audit-log-format — 감사 로그 형식. 기본값은 json이지만 기존 텍스트 형식도 사용할 수 있습니다(legacy).

감사 정책

이제 로깅 정책을 설명하는 언급된 파일에 대해 설명합니다. 감사정책의 첫 번째 개념은 level, 로깅 수준. 그것들은 다음과 같습니다:

None - 기록하지 마세요.
Metadata — 로그 요청 메타데이터: 사용자, 요청 시간, 대상 리소스(포드, 네임스페이스 등), 작업 유형(동사) 등
Request — 로그 메타데이터 및 요청 본문
RequestResponse — 로그 메타데이터, 요청 본문 및 응답 본문.

마지막 두 레벨(Request и RequestResponse) 리소스에 액세스하지 않은 요청(소위 리소스가 아닌 URL에 대한 액세스)을 기록하지 않습니다.

또한 모든 요청이 통과됩니다. 여러 단계:

RequestReceived - 요청이 프로세서에 의해 수신되었지만 아직 프로세서 체인을 따라 더 이상 전송되지 않은 단계
ResponseStarted — 응답 헤더가 전송되지만 응답 본문이 전송되기 전입니다. 장기 실행 쿼리를 위해 생성됩니다(예: watch);
ResponseComplete — 응답 본문이 전송되었으므로 더 이상 정보가 전송되지 않습니다.
Panic — 비정상적인 상황이 감지되면 이벤트가 생성됩니다.

사용할 수 있는 단계를 건너뛰려면 omitStages.

정책 파일에서는 다양한 로깅 수준을 가진 여러 섹션을 설명할 수 있습니다. 정책 설명에 있는 첫 번째 일치 규칙이 적용됩니다.

kubelet 데몬은 api-server 구성을 사용하여 매니페스트의 변경 사항을 모니터링하고, 변경 사항이 감지되면 api-server를 사용하여 컨테이너를 다시 시작합니다. 그러나 중요한 세부 사항이 있습니다. 정책 파일의 변경 사항은 무시됩니다.. 정책 파일을 변경한 후에는 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

다음 감사 정책은 모범 사례의 데모로 제공됩니다. Alibaba Cloud 문서:

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에서 사용되는 프로필.

감사 이벤트에 대한 신속한 대응이 가능합니다. 웹훅 설명. 이 문제는 다음에서 다룹니다. 공식 문서, 이 기사의 범위를 벗어나겠습니다.

결과

이 기사에서는 개인화된 사용자 계정을 생성하고 권한을 분리하며 작업을 기록할 수 있는 Kubernetes 클러스터의 기본 보안 메커니즘에 대한 개요를 제공합니다. 이론상으로나 실제적으로 이런 문제에 직면한 사람들에게 도움이 되기를 바랍니다. 또한 "PS"에 제공되는 Kubernetes 보안 주제에 대한 다른 자료 목록을 읽어보는 것이 좋습니다. 아마도 그 중에서 귀하와 관련된 문제에 대해 필요한 세부 정보를 찾을 수 있을 것입니다.

PS

블로그에서도 읽어보세요.

출처 : habr.com

Kubernetes 보안의 ABC: 인증, 권한 부여, 감사

인증