서비스, API 서버 및 작업자 노드 로그 검토

감사 로그를 사용하면 클러스터의 사용자가 시작한 오퍼레이션을 더 효과적으로 파악할 수 있으므로 문제를 해결하거나 업계 및 내부 표준에 대한 규제 준수를 보고하는 데 도움이 될 수 있습니다.

Kubernetes API 서버 감사 로그

클러스터 내에서 수행된 사용자 시작 Kubernetes 관리 활동을 모니터하기 위해 Kubernetes API 서버를 통해 전달되는 감사 이벤트를 수집하여 IBM Cloud Logs 또는 외부 서버로 전달할 수 있습니다.

고려사항 및 전제조건

Kubernetes API 감사 구성을 설정하기 전에 다음 정보를 검토하십시오.

VPC 클러스터 버전 4.15 이상: 감사 로그는 Red Hat OpenShift 감사 정책 프로필 default (기본값용) 및 WriteRequestBodies(상세 설명용)을 사용합니다. 자세한 정보는 감사 로그 정책을 참조하십시오.
기타 모든 클러스터 버전: 감사 로그는 kube-samples repo의 openshift-audit 정책을 사용합니다.

기본 정책을 수정하거나 고유한 사용자 정의 정책을 적용할 수 없습니다.

Kubernetes 의 감사 로그 및 상세 수준에 대해서는 Kubernetes 문서를 참조하십시오.
클러스터에는 하나의 감사 웹훅만 작성할 수 있습니다.
Red Hat OpenShift on IBM Cloud 클러스터에 대한 관리자 IBM Cloud IAM 플랫폼 액세스 역할 이 있어야 합니다.

시작하려면 지침에 따라 Kubernetes API 감사 로그를 IBM Cloud 사설 네트워크 내의 리소스로 전송하십시오.

Kubernetes API 감사 로그를 Cloud Logs로 전달하기

감사 로그를 IBM Cloud Logs에 전달하도록 제공된 이미지 및 배치를 사용하여 Kubernetes 감사 시스템을 작성할 수 있습니다.

다음 예제는 이미지를 icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs 사용하여 로그를 IBM Cloud Logs 으로 전달합니다. 개념 증명만 필요한 경우 보안 설정 단계를 건너뛸 수 있습니다. 보다 자동화된 솔루션을 위해 자체 로그 전달 이미지를 구성하고 유지 관리하십시오.

이전에는 로그를 전달하는 데 icr.io/ibm/ibmcloud-kube-audit-to-logdna 가 사용되었습니다. 이 이미지는 더 이상 사용되지 않으며 지원이 곧 종료됩니다. 로그 전달 설정을 업데이트하여 icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs 를 대신 사용하십시오.

클러스터의 Kubernetes 감사 시스템은 감사 웹훅, 로그 콜렉션 서비스 및 웹 서버 앱, 로깅 에이전트로 구성됩니다. 웹훅은 클러스터 마스터에서 Kubernetes API 서버 이벤트를 수집합니다. 로그 콜렉션 서비스는 공용 IBM Cloud 레지스트리의 이미지에서 작성된 Kubernetes ClusterIP 서비스입니다. 이 서비스는 클러스터 네트워크 내에서만 접근 가능한 간단한 HTTP 웹 서버 애플리케이션을 제공합니다. 이 웹 서버 앱은 감사 웹훅의 로그 데이터를 구문 분석하고 각 로그를 고유한 JSON 행으로 작성합니다. 마지막으로, 로깅 에이전트는 웹 서버 애플리케이션의 로그를 IBM Cloud Logs 으로 전달하며, 해당 페이지에서 로그를 확인할 수 있습니다.

시작하기 전에: ‘ 고려 사항 및 전제 조건 ’ 문서를 반드시 확인하셨는지, 그리고 IBM Cloud Logs 에 대한 관리자 IBM Cloud IAM 플랫폼 액세스 역할 를 보유하고 계신지 확인해 주십시오.

공용 IBM Cloud 이미지에 대한 글로벌 컨테이너 레지스트리를 대상으로 지정하십시오.
```
ibmcloud cr region-set global
```
선택 사항: ‘ kube-audit ’ 이미지에 대한 자세한 내용은 icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs 을 참조하십시오.
```
ibmcloud cr image-inspect icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs
```
클러스터에 접근하기 위해 kubeconfig를 설정하세요
```
ibmcloud ks cluster config -c CLUSTER
```

ibmcloud-kube-audit.yaml이라는 구성 파일을 작성하십시오. 이 구성 파일은 로그 수집 서비스를 생성하고, icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs 이미지를 가져와 로그 수집 컨테이너를 생성하는 배포를 설정합니다.

apiVersion: v1
kind: List
metadata:
  name: ibmcloud-kube-audit
items:
  - apiVersion: v1
    kind: Namespace
    metadata:
      name: ibm-kube-audit
      labels:
        pod-security.kubernetes.io/enforce: restricted
        pod-security.kubernetes.io/enforce-version: latest
        pod-security.kubernetes.io/audit: restricted
        pod-security.kubernetes.io/audit-version: latest
        pod-security.kubernetes.io/warn: restricted
        pod-security.kubernetes.io/warn-version: latest
        security.openshift.io/scc.podSecurityLabelSync: "false"
  - apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ibmcloud-kube-audit
      namespace: ibm-kube-audit
      labels:
        app: ibmcloud-kube-audit
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: ibmcloud-kube-audit
      template:
        metadata:
          labels:
            app: ibmcloud-kube-audit
        spec:
          containers:
            - name: ibmcloud-kube-audit
              image: 'icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs:latest'
              imagePullPolicy: Always
              ports:
                - containerPort: 3000
                - containerPort: 4443
              securityContext:
                allowPrivilegeEscalation: false
                runAsNonRoot: true
                capabilities:
                  drop:
                  - ALL
                seccompProfile:
                  type: RuntimeDefault
              volumeMounts:
                - mountPath: /certificates
                  name: certificates
                  readOnly: true
          volumes:
            - name: certificates
              secret:
                secretName: audit-webhook
                optional: true
  - apiVersion: v1
    kind: Service
    metadata:
      name: ibmcloud-kube-audit-service
      namespace: ibm-kube-audit
      labels:
        app: ibmcloud-kube-audit
    spec:
      selector:
        app: ibmcloud-kube-audit
      ports:
        - name: http
          protocol: TCP
          port: 80
          targetPort: 3000
        - name: https
          protocol: TCP
          port: 443
          targetPort: 4443
      type: ClusterIP
  - kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: ibmcloud-kube-audit
      namespace: ibm-kube-audit
    spec:
      podSelector:
        matchLabels:
          app: ibmcloud-kube-audit
      policyTypes:
      - Ingress
      ingress:
      - ports:
        - protocol: TCP
          port: 3000
        - protocol: TCP
          port: 4443
        from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              app: konnectivity-agent
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              app: vpn

클러스터의 ‘ ibm-kube-audit ’ 네임스페이스에서 배포를 생성합니다.
```
kubectl apply -f ibmcloud-kube-audit.yaml
```

배포 ibmcloud-kube-audit 상태가 사용 가능 상태가 될 때까지 기다리십시오.

kubectl wait --for condition=Available --namespace ibm-kube-audit --timeout 5m deploy/ibmcloud-kube-audit

출력 예

deployment.apps/ibmcloud-kube-audit condition met

ibmcloud-kube-audit-service 서비스가 클러스터에 배치되어 있는지 확인하십시오.

kubectl get svc -n ibm-kube-audit -l app=ibmcloud-kube-audit

출력 예

NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
ibmcloud-kube-audit-service   ClusterIP   172.21.xxx.xxx   <none>        80/TCP           1m

HTTPS 로 전송 중인 트래픽을 암호화합니다. 개념 증명용 감사 로그 전달기만 필요한 경우 이 단계를 건너뛰십시오.
인증 기관 상태를 확인합니다. 인증서의 만료가 임박한 경우, 인증서를 교체하는 단계를 따르세요.
```
ibmcloud oc cluster ca status -c CLUSTER
```

클러스터의 certificate-authority 를 파일 에 cluster-ca.pem 저장하십시오.

ibmcloud oc cluster ca get -c CLUSTER --output json | jq -r .caCert | base64 -D > cluster-ca.pem

계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오. 인증서 기반 kubeconfig를 준비하고 다음 위치에 저장하십시오 kubeconfig.json. 로컬 머신에 및 client-certificate 데이터를 client-key 다운로드하려면 옵션을 --admin 반드시 지정하십시오. 이 데이터는 나중에 감사 웹훅을 구성하는 데 사용됩니다.
```
ibmcloud oc cluster config --cluster CLUSTER --admin --output json > kubeconfig.json
```
kubeconfig의 소유자가 삭제되거나 해당 권한이 취소되면, 쿠버네티스 API 서버는 더 이상 감사 로그를 전송할 수 없게 됩니다. 이러한 상황을 방지하기 위해, 이 작업에는 특정 사용자가 아닌 계정과 직접 연동되는 서비스 ID를 사용하는 것을 권장합니다.

kubeconfig의 클라이언트 인증서를 파일로 추출하십시오 kubeconfig-cert.pem.

jq -r '.users[].user."client-certificate-data"' kubeconfig.json | base64 -D > kubeconfig-cert.pem

kubeconfig의 클라이언트 키를 파일로 추출합니다 kubeconfig-key.pem.

jq -r '.users[].user."client-key-data"' kubeconfig.json | base64 -D > kubeconfig-key.pem

감사 웹훅을 구성하고 certificate-authority, client-certificate 및 client-key를 지정하십시오. 단계 10 에서 가 certificate-authority 검색되었으며, 이전 두 단계에서 와 client-certificate 가 client-key 검색되었습니다. 선택적으로 다른 값으로 policy 설정할 수 있습니다.

ibmcloud oc cluster master audit-webhook set \
    --cluster CLUSTER \
    --remote-server https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/http:ibmcloud-kube-audit-service:http/proxy/post \
    --ca-cert cluster-ca.pem \
    --client-cert kubeconfig-cert.pem \
    --client-key kubeconfig-key.pem \
    --policy default

단계 8 에서 HTTPS 을 구성한 경우, 대신 이 주소 https``remote-serverURL 을 설정하십시오:

https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/https:ibmcloud-kube-audit-service:https/proxy/post

감사 웹훅이 클러스터에 작성되었는지 확인하십시오.

ibmcloud oc cluster master audit-webhook get --cluster CLUSTER

출력 예

Server:   https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/http:ibmcloud-kube-audit-service:http/proxy/post
Policy:   default

클러스터 마스터를 새로 고쳐서 Kubernetes API 서버에 웹훅을 적용하십시오. 마스터를 새로 고치는 데 몇 분이 걸릴 수 있습니다.
```
ibmcloud oc cluster master refresh --cluster CLUSTER
```
마스터를 새로 고치는 동안 IBM Cloud Logs의 인스턴스를 프로비저닝하고 클러스터의 모든 작업자 노드에 로깅 에이전트를 배치하십시오. 클러스터 내부의 로그를 IBM Cloud Logs 서비스로 전달하려면 로깅 에이전트가 필요합니다. 클러스터에서 로깅 에이전트를 이미 설정한 경우 이 단계를 건너뛸 수 있습니다.
클러스터 상태를 확인하고 가 Master State 를 나타낼 때까지 기다린 후, 상태 updating 가 될 때까지 deployed 기다립니다. 완료되는 데 몇 분 정도 걸릴 수 있습니다.
```
ibmcloud ks cluster get -c CLUSTER
```
출력 예
```
...
Master
Status:     Refresh in progress. (2 seconds ago)
State:      updating
...
Master
Status:     Ready (2 seconds ago)
State:      deployed
```
마스터 새로 고치기가 완료되고 로깅 에이전트가 작업자 노드에서 실행되고 나면 IBM Cloud Logs에서 Kubernetes API 감사 로그를 확인할 수 있습니다.

클러스터에서 감사 웹훅을 설정한 후에는 ibmcloud cr image-list --include-ibm | grep ibmcloud-kube-audit-to-ibm-cloud-logs 을 실행하여 ibmcloud-kube-audit-to-ibm-cloud-logs 이미지의 버전 업데이트를 모니터링할 수 있습니다. 현재 클러스터에서 실행되는 이미지의 버전을 보려면 oc get pods | grep ibmcloud-kube-audit-to-ibm-cloud-logs를 실행하여 감사 팟(Pod) 이름을 찾고 kubectl describe pod <pod_name>을 실행하여 이미지 버전을 확인하십시오. 현재 태그에서 사용 가능한 최신 버전으로 포드를 업데이트하고 kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit, 새 포드가 사용 가능해질 때까지 기다립니다. kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit

HTTPS 로 업데이트 관리, 인증서 교체 및 전송 중 암호화 수행

로그 전달을 준비하기 전에 유의해야 할 몇 가지 중요한 사항:

이미지 태그는 취약점 및 버그 수정 icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs:latest 업데이트를 받습니다. 그러나 해당 변경 사항을 반영하려면 배포를 수동으로 다시 시작해야 합니다. 를 kubectl rollout restart -n ibm-kube-audit deploy/ibmcloud-kube-audit 사용하여 최신 이미지를 가져오고 우아하게 재시작하십시오.
이 배포는 수동으로 설치 및 관리됩니다. 이 배포 환경에서 다른 환경으로 전환할 경우 감사 로그 중단 시간이 발생할 수 있습니다.
다음 단계에서 생성된 인증서는 갱신할 수 있습니다. 회전에는 비밀을 교체하고 배포를 재시작하기 위한 수동 단계가 필요합니다.

전송 중 암호화를 통해 배포를 보호하려면, kube-apiserver가 서명한 개인 키와 TLS 인증서가 필요합니다.

4단계 에서 YAML 파일을 적용한 후, 서비스 리소스가 클러스터 IP를 채울 때까지 기다리십시오. 그것을 셸 변수에 저장하십시오 $cluster_ip.

cluster_ip=$(
    kubectl wait \
        --for jsonpath='{.spec.clusterIP}' \
        --namespace ibm-kube-audit \
        --output jsonpath='{.spec.clusterIP}' \
        --timeout 5m \
        svc/ibmcloud-kube-audit-service
)

개인 키를 생성하고 저장하세요. server.key
```
openssl genrsa -out server.key 4096
```

인증서 서명 요청(CSR) 구성 파일을 생성합니다 server-csr.conf. 이것은 Kubernetes 이 서명할 인증서를 생성하는 데 사용됩니다.

cat <<EOF > server-csr.conf
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
CN = system:node:ibmcloud-kube-audit-service.ibm-kube-audit.svc
O = system:nodes
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = ibmcloud-kube-audit-service.ibm-kube-audit.svc.cluster.local
DNS.2 = ibmcloud-kube-audit-service.ibm-kube-audit.svc
IP.1 = ${cluster_ip}
EOF

Kubernetes 가 서명할 수 있도록 인증서 서명 요청 페이로드를 생성하십시오.
```
openssl req -new -config server-csr.conf -key server.key -out server.csr
```

KubernetesCertificateSigningRequest (CSR) 리소스에 페이로드를 삽입하십시오

kubectl apply -f - <<EOF
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: ibmcloud-kube-audit-service.ibm-kube-audit
spec:
  request: $(base64 < server.csr | tr -d '\n')
  signerName: kubernetes.io/kubelet-serving
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF

요청 승인

kubectl certificate approve ibmcloud-kube-audit-service.ibm-kube-audit

인증서가 서명될 때까지 기다리십시오

kubectl wait \
    --for jsonpath='{.status.certificate}' \
    --output go-template='{{.status.certificate | base64decode}}' \
    --timeout 5m \
    csr/ibmcloud-kube-audit-service.ibm-kube-audit > server.crt

인증서와 개인 키로 비밀 키 생성

kubectl create secret tls \
    --cert server.crt \
    --key server.key \
    --namespace ibm-kube-audit \
    audit-webhook

배포를 다시 시작하여 새 시크릿을 적용하십시오.

kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit

새로운 포드가 이용 가능해질 때까지 기다려 주세요

kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit

감사 웹훅이 이제 암호화된 연결을 통해 이벤트를 수신할 준비가 되었습니다. “ Kubernetes API 감사 로그를 Cloud Logs로 전달” 섹션에서 감사 웹훅을 구성할 때는 --remote-server URL 의 https 버전을 대신 사용해야 합니다
```
https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/https:ibmcloud-kube-audit-service:https/proxy/post`
```

IBM Cloud 사설 네트워크의 리소스에 Kubernetes API 감사 로그 전달

클러스터 외부에 있고 IBM Cloud Logs 사설 네트워크에서 액세스할 수 있는 IBM Cloud 이외의 리소스로 감사 로그를 전달하십시오.

다음 예제에서는 haproxytech/haproxy-alpine:2.6 이미지를 사용하여 로그를 전달합니다. 이 이미지는 데모용으로만 사용되며 프로덕션 환경에서는 사용할 수 없습니다. 프로덕션 솔루션의 경우 자체 로그 전달 이미지를 구성하고 유지보수하십시오.

시작하기 전에 고려사항 및 전제조건을 검토했는지 확인하십시오.

새 디렉토리 kube-audit-forwarder 를 작성하고 여기에 다음 컨텐츠를 포함하는 haproxy.cfg 파일을 작성하십시오. 파일의 <REMOTE-IP>:<REMOTE-PORT> 를 원격 로그 이용자의 IP 주소 및 포트로 바꾸는 것을 잊지 마십시오.
```
global
  log stdout format raw local0 info
defaults
  mode http
  timeout client 10s
  timeout connect 5s
  timeout server 10s
  timeout http-request 10s
  log global
frontend myfrontend
  bind :3000
  default_backend remotelogstash
# Use remote log consumer IP and port here
backend remotelogstash
  server s1 <REMOTE-IP>:<REMOTE-PORT> check
```
로그 소비자 서버에서 보안 연결을 적용하는 경우( TLS ), 이 디렉터리에 인증서 파일을 추가하고 haproxy.cfg 에서 백엔드 섹션을 변경하여 이러한 파일을 사용할 수 있습니다. 자세한 내용은 HAProxy 문서를 참조하세요.

kube-audit-forwarder 디렉토리의 컨텐츠에서 configmap을 작성하십시오.

kubectl create namespace ibm-kube-audit; kubectl create configmap -n ibm-kube-audit kube-audit-forwarder-cm --from-file=kube-audit-forwarder

kube-audit-forwarder-remote-private-ip.yaml 라는 이름의 구성 파일을 생성합니다. 이 구성 파일은 IBM Cloud 사설 네트워크를 통해 클러스터의 감사 로그를 원격 리소스의 IP 주소로 전달하는 배치 및 서비스를 작성합니다.

kind: Deployment
apiVersion: apps/v1
metadata:
  labels:
    app: kube-audit-forwarder
  name: kube-audit-forwarder
  namespace: ibm-kube-audit
spec:
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: kube-audit-forwarder
  strategy:
    rollingUpdate:
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: kube-audit-forwarder
    spec:
      containers:
      - image: haproxytech/haproxy-alpine:2.6
        imagePullPolicy: IfNotPresent
        name: haproxy
        volumeMounts:
        - name: config-volume
          mountPath: /usr/local/etc/haproxy/haproxy.cfg
          subPath: haproxy.cfg
      volumes:
      - name: config-volume
        configMap:
          name: kube-audit-forwarder-cm
---
apiVersion: v1
kind: Service
metadata:
  name: kube-audit-forwarder
  namespace: ibm-kube-audit
spec:
  selector:
    app: kube-audit-forwarder
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: kube-audit-forwarder
  namespace: ibm-kube-audit
spec:
  podSelector:
    matchLabels:
      app: kube-audit-forwarder
  policyTypes:
  - Ingress
  ingress:
  - ports:
    - protocol: TCP
      port: 3000
    from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: konnectivity-agent
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          app: konnectivity-agent
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          app: vpn

이전 단계에서 kube-audit-forwarder 에 인증서 파일을 추가한 경우 volumeMounts 섹션에 해당 파일을 subPath 로 나열하는 것을 잊지 마십시오.

배포 및 서비스를 생성합니다.

kubectl create -f kube-audit-forwarder-remote-private-ip.yaml

클러스터에 ‘ kube-audit-forwarder ’ 배포 및 서비스가 배포되어 있는지 확인하십시오.

kubectl get svc -n ibm-kube-audit

출력 예

NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
...
kube-audit-forwarder  ClusterIP   10.xxx.xx.xxx   <none>        80/TCP           1m

kubectl get deployment -n ibm-kube-audit

출력 예

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
...
kube-audit-forwarder   1/1     1            1           6m27s

계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오. --admin 옵션을 반드시 지정하여 client-certificate 및 client-key 파일을 로컬 컴퓨터에 다운로드하십시오. 이러한 파일은 나중에 감사 웹훅을 구성하는 데 사용됩니다.
```
ibmcloud oc cluster config --cluster CLUSTER --admin
```
인증 기관 상태를 확인합니다. 인증서의 만료가 임박한 경우, 인증서를 교체하는 단계를 따르세요.
```
ibmcloud oc cluster ca status -c CLUSTER
```

클러스터의 certificate-authority 를 조회하여 파일로 저장합니다.

 ibmcloud oc cluster ca get -c CLUSTER --output json | jq -r .caCert | base64 -D > CERTIFICATE_AUTHORITY

oc config view 명령을 실행하여 현재 구성을 보고 client-certificate 및 client-key의 출력을 검토하십시오.

oc config view --minify

출력 예

clusters:
- cluster:
    ...
    ...
    client-certificate: /Users/user/.bluemix/plugins/container-service/clusters/cluster-name-a111a11a11aa1aa11a11-admin/admin.pem
    client-key: /Users/user/.bluemix/plugins/container-service/clusters/cluster-name-a111a11a11aa1aa11a11-admin/admin-key.pem

감사 웹훅을 구성하고 5-7단계에서 검색한 certificate-authority, client-certificate 및 client-key 를 지정하십시오.

ibmcloud oc cluster master audit-webhook set --cluster CLUSTER --remote-server https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/kube-audit-forwarder/proxy/post --ca-cert CERTIFICATE_AUTHORITY --client-cert CLIENT_CERTIFICATE --client-key CLIENT_KEY [--policy default|verbose]

감사 웹훅이 클러스터에 작성되었는지 확인하십시오.

ibmcloud oc cluster master audit-webhook get --cluster CLUSTER_NAME_OR_ID

출력 예

OK
Server:            https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/kube-audit-forwarder/proxy/post
Policy:            default

클러스터 마스터를 새로 고쳐서 Kubernetes API 서버에 웹훅을 적용하십시오. 마스터를 새로 고치는 데는 몇 분이 소요될 수 있습니다.
```
ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID
```

마스터 새로 고치기가 완료되고 나면 로그가 로깅 리소스의 사설 IP 주소로 전송됩니다.

작업자 노드 감사 로그

Red Hat OpenShift on IBM Cloud는 Linux 감사 시스템 컴포넌트인 auditd를 사용하여 작업자 노드의 활동을 모니터하고 로깅합니다. 워커 노드 감사 기능은 기본적으로 활성화되어 있지만, IBM Cloud Logs 인스턴스나 외부 서버로 로그 전달을 설정하기 전까지는 감사 데이터를 확인할 수 없습니다.

작업자 노드 감사 구성 이해

로그는 작업자 노드의 /var/log/audit 디렉토리에 저장됩니다. 로그 전달을 설정한 후 IBM Cloud Logs 또는 외부 서버에서 로그를 볼 수 있습니다.

Auditd는 다음을 포함하여 다양한 이벤트에 대한 로그를 수집합니다.

Linux 시스템 호출(syscalls)
SELinux 거부
SELinux 정책 수정사항
yum 패키지 설치 프로그램을 통한 소프트웨어 수정
Systemd 오퍼레이션
Linux 사용자 및 그룹 수정
Netfilter 변경 수정사항
SSH 로그인

작업자 노드에 대한 로그 전달 설정

IBM Cloud Logs 인스턴스에 로그 전달을 참조하십시오.

서비스 감사 로그

기본적으로 Red Hat OpenShift on IBM Cloud는 이벤트를 생성하여 IBM Cloud Logs에 전송합니다. 이러한 이벤트를 보려면 IBM Cloud Logs 인스턴스를 작성해야 합니다. 자세한 정보는 IBM Cloud Logs 이벤트를 참조하십시오.

감사 사용 클러스터에서 `AuditWebhookError` 경보 보기

Red Hat OpenShift on IBM Cloud 클러스터 버전에는 감사 웹훅이 중단되거나 삭제될 때 발동되는 경고가 AuditWebhookError 있습니다.

경보를 보려면 다음을 수행하십시오.

계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.

Red Hat OpenShift on IBM Cloud에서 관리자 보기를 선택하십시오.
관찰 > 경고 > AuditWebhookError 를 클릭합니다.
이 경보에 대한 알림을 작성하려면 외부 시스템에 알림 전송을 참조하십시오.

서비스, API 서버 및 작업자 노드 로그 검토

서비스, API 서버 및 작업자 노드 로그 검토

Kubernetes API 서버 감사 로그

고려사항 및 전제조건

Kubernetes API 감사 로그를 Cloud Logs로 전달하기

HTTPS 로 업데이트 관리, 인증서 교체 및 전송 중 암호화 수행

IBM Cloud 사설 네트워크의 리소스에 Kubernetes API 감사 로그 전달

작업자 노드 감사 로그

작업자 노드 감사 구성 이해

작업자 노드에 대한 로그 전달 설정

서비스 감사 로그

감사 사용 클러스터에서 AuditWebhookError 경보 보기

감사 사용 클러스터에서 `AuditWebhookError` 경보 보기