Kubernetes의 Seccomp: 처음부터 알아야 할 7가지

메모. 번역: 영국 회사 ASOS.com의 수석 애플리케이션 보안 엔지니어가 번역한 기사를 여러분께 소개합니다. 이를 통해 그는 seccomp를 사용하여 Kubernetes의 보안을 향상시키는 데 전념하는 일련의 간행물을 시작합니다. 독자들이 소개를 좋아한다면 저자를 따라가며 이 주제에 대한 향후 자료를 계속해서 작성할 것입니다.

이 기사는 마술이나 요술에 의지하지 않고 SecDevOps 정신으로 seccomp 프로필을 만드는 방법에 대한 일련의 게시물 중 첫 번째입니다. XNUMX부에서는 Kubernetes에서 seccomp 구현에 대한 기본 사항과 내부 세부 정보를 다루겠습니다.

Kubernetes 생태계는 컨테이너를 보호하고 격리하는 다양한 방법을 제공합니다. 이 문서는 보안 컴퓨팅 모드(Secure Computing Mode)에 관한 것입니다. 초컴. 그 핵심은 컨테이너에서 실행할 수 있는 시스템 호출을 필터링하는 것입니다.

왜 중요 함? 컨테이너는 특정 머신에서 실행되는 프로세스일 뿐입니다. 그리고 다른 응용 프로그램과 마찬가지로 커널을 사용합니다. 컨테이너가 시스템 호출을 수행할 수 있다면 곧 맬웨어가 이를 활용하여 컨테이너 격리를 우회하고 정보 가로채기, 시스템 설정 변경 등 다른 애플리케이션에 영향을 미칠 것입니다.

seccomp 프로필은 허용하거나 비활성화해야 하는 시스템 호출을 정의합니다. 컨테이너 런타임은 커널이 실행을 모니터링할 수 있도록 시작할 때 이를 활성화합니다. 이러한 프로필을 사용하면 컨테이너 내부의 프로그램(즉, 종속성 또는 해당 종속성)이 허용되지 않는 작업을 시작하는 경우 공격 벡터를 제한하고 피해를 줄일 수 있습니다.

기본 사항 알아보기

기본 seccomp 프로필에는 다음 세 가지 요소가 포함됩니다. defaultAction, architectures (또는 archMap) 그리고 syscalls:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "sched_yield",
                "futex",
                "write",
                "mmap",
                "exit_group",
                "madvise",
                "rt_sigprocmask",
                "getpid",
                "gettid",
                "tgkill",
                "rt_sigaction",
                "read",
                "getpgrp"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(중간-기본-seccomp.json)

defaultAction 섹션에 지정되지 않은 시스템 호출의 기본 운명을 결정합니다. syscalls. 작업을 더 쉽게 하기 위해 사용될 두 가지 주요 값에 중점을 두겠습니다.

• SCMP_ACT_ERRNO — 시스템 호출 실행을 차단합니다.
• SCMP_ACT_ALLOW - 허용합니다.

섹션에서 architectures 대상 아키텍처가 나열됩니다. 커널 수준에서 적용되는 필터 자체는 프로필에 지정된 이름이 아니라 시스템 호출 식별자에 의존하기 때문에 이는 중요합니다. 컨테이너 런타임은 사용하기 전에 이를 식별자와 일치시킵니다. 아이디어는 시스템 호출이 시스템 아키텍처에 따라 완전히 다른 ID를 가질 수 있다는 것입니다. 예를 들어 시스템 호출 recvfrom (소켓에서 정보를 수신하는 데 사용됨)은 x64 시스템에서 ID = 64이고 x517에서 ID = 86입니다. 여기에 x86-x64 아키텍처에 대한 모든 시스템 호출 목록을 찾을 수 있습니다.

섹션에서 syscalls 모든 시스템 호출을 나열하고 이에 대해 수행할 작업을 지정합니다. 예를 들어, 다음을 설정하여 화이트리스트를 생성할 수 있습니다. defaultAction 에 SCMP_ACT_ERRNO, 섹션에서 전화 syscalls 할당 SCMP_ACT_ALLOW. 따라서 섹션에 지정된 통화만 허용됩니다. syscalls, 기타 모든 것을 금지합니다. 블랙리스트의 경우 값을 변경해야 합니다. defaultAction 그리고 그 반대의 행동.

이제 우리는 그다지 명확하지 않은 뉘앙스에 대해 몇 마디 말해야 합니다. 아래 권장 사항은 Kubernetes에 LOB(기간 업무) 애플리케이션을 배포하고 가능한 최소한의 권한으로 실행하기를 원한다고 가정합니다.

1. AllowPrivilegeEscalation=false

В securityContext 컨테이너에 매개변수가 있습니다 AllowPrivilegeEscalation. 에 설치되어 있는 경우 false, 컨테이너는 (on) 조금 no_new_priv. 이 매개변수의 의미는 이름에서 분명합니다. 즉, 컨테이너가 자체 보유 권한보다 더 많은 권한을 사용하여 새 프로세스를 시작하는 것을 방지합니다.

이 옵션을 다음과 같이 설정하면 부작용이 발생합니다. true (기본값)은 컨테이너 런타임이 시작 프로세스의 맨 처음에 seccomp 프로필을 적용한다는 것입니다. 따라서 내부 런타임 프로세스(예: 사용자/그룹 ID 설정, 특정 기능 삭제)를 실행하는 데 필요한 모든 시스템 호출을 프로필에서 활성화해야 합니다.

사소한 일을 하는 컨테이너에 echo hi, 다음 권한이 필요합니다:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "brk",
                "capget",
                "capset",
                "chdir",
                "close",
                "execve",
                "exit_group",
                "fstat",
                "fstatfs",
                "futex",
                "getdents64",
                "getppid",
                "lstat",
                "mprotect",
                "nanosleep",
                "newfstatat",
                "openat",
                "prctl",
                "read",
                "rt_sigaction",
                "statfs",
                "setgid",
                "setgroups",
                "setuid",
                "stat",
                "uname",
                "write"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(hi-pod-seccomp.json)

...이것 대신에:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "brk",
                "close",
                "execve",
                "exit_group",
                "futex",
                "mprotect",
                "nanosleep",
                "stat",
                "write"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(hi-컨테이너-seccomp.json)

그런데 또 이게 왜 문제가 되는 걸까요? 개인적으로 나는 다음 시스템 호출을 화이트리스트에 추가하는 것을 피하고 싶습니다(실제로 필요한 경우가 아닌 이상). capset, set_tid_address, setgid, setgroups и setuid. 그러나 실제 과제는 전혀 제어할 수 없는 프로세스를 허용함으로써 프로필을 컨테이너 런타임 구현에 연결한다는 것입니다. 즉, 어느 날 컨테이너 런타임 환경을 업데이트한 후(귀하 또는 클라우드 서비스 제공업체에 의해) 컨테이너 실행이 갑자기 중단되는 것을 발견할 수 있습니다.

팁 # 1: 다음을 사용하여 컨테이너를 실행합니다. AllowPrivilegeEscaltion=false. 이렇게 하면 seccomp 프로필의 크기가 줄어들고 컨테이너 런타임 환경의 변경에 덜 민감해집니다.

2. 컨테이너 수준에서 seccomp 프로필 설정

seccomp 프로필은 포드 수준에서 설정할 수 있습니다.

annotations:
  seccomp.security.alpha.kubernetes.io/pod: "localhost/profile.json"

...또는 컨테이너 수준에서:

annotations:
  container.security.alpha.kubernetes.io/<container-name>: "localhost/profile.json"

Kubernetes seccomp가 실행되면 위 구문이 변경됩니다. GA가 될 것이다 (이 이벤트는 Kubernetes의 다음 릴리스 - 1.18 - 대략적인 번역에서 예상됩니다.)

Kubernetes가 항상 그랬다는 사실을 아는 사람은 거의 없습니다. 버그이로 인해 seccomp 프로필이 적용되었습니다. 일시 중지 컨테이너. 런타임 환경은 이러한 단점을 부분적으로 보완하지만 이 컨테이너는 인프라를 구성하는 데 사용되므로 Pod에서 사라지지 않습니다.

문제는 이 컨테이너가 항상 다음으로 시작한다는 것입니다. AllowPrivilegeEscalation=true, 이는 단락 1에서 언급된 문제로 이어지며 이는 변경할 수 없습니다.

컨테이너 수준에서 seccomp 프로필을 사용하면 이러한 함정을 피하고 특정 컨테이너에 맞는 프로필을 생성할 수 있습니다. 개발자가 버그를 수정하고 모든 사람이 새 버전(1.18?)을 사용할 수 있게 될 때까지 이 작업을 수행해야 합니다.

팁 # 2: 컨테이너 수준에서 seccomp 프로필을 설정합니다.

실제적인 의미에서 이 규칙은 일반적으로 "내 seccomp 프로필이 왜 작동합니까?"라는 질문에 대한 보편적인 대답으로 사용됩니다. docker run하지만 Kubernetes 클러스터에 배포한 후에는 작동하지 않나요?

3. 런타임/기본값은 최후의 수단으로만 사용하십시오.

Kubernetes에는 기본 제공 프로필에 대한 두 가지 옵션이 있습니다. runtime/default и docker/default. 둘 다 Kubernetes가 아닌 컨테이너 런타임에 의해 구현됩니다. 따라서 사용되는 런타임 환경 및 버전에 따라 다를 수 있습니다.

즉, 런타임 변경의 결과로 컨테이너는 사용하거나 사용하지 않을 수 있는 다른 시스템 호출 집합에 액세스할 수 있습니다. 대부분의 런타임은 도커 구현. 이 프로필을 사용하려면 자신에게 적합한지 확인하세요.

프로필 docker/default Kubernetes 1.11부터 더 이상 사용되지 않으므로 사용하지 마세요.

내 생각엔 프로필이 runtime/default 작성된 목적에 완벽하게 적합합니다. 명령 실행과 관련된 위험으로부터 사용자를 보호합니다. docker run 그들의 차에. 그러나 Kubernetes 클러스터에서 실행되는 비즈니스 애플리케이션의 경우 그러한 프로필은 너무 개방적이므로 개발자는 애플리케이션(또는 애플리케이션 유형)에 대한 프로필을 만드는 데 집중해야 한다고 감히 주장하고 싶습니다.

팁 # 3: 특정 응용 프로그램에 대한 seccomp 프로필을 만듭니다. 이것이 가능하지 않은 경우 애플리케이션 유형에 대한 프로필을 생성하십시오. 예를 들어 Golang 애플리케이션의 모든 웹 API를 포함하는 고급 프로필을 생성하십시오. 최후의 수단으로만 런타임/기본값을 사용하십시오.

향후 게시물에서는 SecDevOps에서 영감을 받은 seccomp 프로필을 생성하고 자동화하고 파이프라인에서 테스트하는 방법을 다루겠습니다. 즉, 애플리케이션별 프로필로 업그레이드하지 않을 이유가 없습니다.

4. 무제한은 옵션이 아닙니다.

으로 첫 번째 Kubernetes 보안 감사 그것은 기본적으로 밝혀졌습니다 seccomp 비활성화됨. 즉, 설정하지 않으면 PodSecurityPolicy클러스터에서 활성화하면 seccomp 프로필이 정의되지 않은 모든 포드가 작동합니다. seccomp=unconfined.

이 모드에서 작동하면 클러스터를 보호하는 전체 절연 층이 손실됩니다. 보안 전문가는 이 접근 방식을 권장하지 않습니다.

팁 # 4: 클러스터의 어떤 컨테이너도 실행 중이 아니어야 합니다. seccomp=unconfined, 특히 프로덕션 환경에서.

5. "감사 모드"

이 점은 Kubernetes에만 국한된 것은 아니지만 여전히 "시작하기 전에 알아야 할 사항" 범주에 속합니다.

공교롭게도 seccomp 프로필을 만드는 것은 항상 어려운 일이며 시행착오에 크게 의존합니다. 사실 사용자는 애플리케이션을 "삭제"할 위험 없이 프로덕션 환경에서 이를 테스트할 기회가 없습니다.

Linux 커널 4.14 릴리스 이후 감사 모드에서 프로필의 일부를 실행하여 모든 시스템 호출에 대한 정보를 syslog에 기록하지만 이를 차단하지 않는 것이 가능해졌습니다. 매개변수를 사용하여 이 모드를 활성화할 수 있습니다. SCMT_ACT_LOG:

SCMP_ACT_LOG: seccomp는 필터의 규칙과 일치하지 않는 경우 시스템 호출을 만드는 스레드에 영향을 미치지 않지만 시스템 호출에 대한 정보는 기록됩니다.

이 기능을 사용하기 위한 일반적인 전략은 다음과 같습니다.

1. 필요한 시스템 호출을 허용합니다.
2. 유용하지 않을 것으로 예상되는 시스템의 호출을 차단하세요.
3. 다른 모든 통화에 대한 정보를 로그에 기록합니다.

단순화된 예는 다음과 같습니다.

{
    "defaultAction": "SCMP_ACT_LOG",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "sched_yield",
                "futex",
                "write",
                "mmap",
                "exit_group",
                "madvise",
                "rt_sigprocmask",
                "getpid",
                "gettid",
                "tgkill",
                "rt_sigaction",
                "read",
                "getpgrp"
            ],
            "action": "SCMP_ACT_ALLOW"
        },
        {
            "names": [
                "add_key",
                "keyctl",
                "ptrace"
            ],
            "action": "SCMP_ACT_ERRNO"
        }
    ]
}

(중간 혼합-seccomp.json)

그러나 사용되지 않을 것으로 알고 클러스터에 잠재적으로 해를 끼칠 수 있는 모든 호출을 차단해야 한다는 점을 기억하십시오. 목록을 작성하기 위한 좋은 기초는 공식 도커 문서. 기본 프로필에서 차단되는 시스템 호출과 그 이유를 자세히 설명합니다.

그러나 한 가지 문제가 있습니다. 하지만 SCMT_ACT_LOG 2017년 말부터 Linux 커널의 지원을 받아 Kubernetes 생태계에 들어온 것은 비교적 최근입니다. 따라서 이 방법을 사용하려면 Linux 커널 4.14 및 runC 버전 이상이 필요합니다. v1.0.0-rc9.

팁 # 5: 블랙리스트와 화이트리스트를 결합하여 프로덕션 테스트를 위한 감사 모드 프로필을 생성할 수 있으며 모든 예외를 기록할 수 있습니다.

6. 화이트리스트 사용

화이트리스트에는 애플리케이션에 필요할 수 있는 모든 호출을 식별해야 하기 때문에 추가 노력이 필요하지만 이 접근 방식을 사용하면 보안이 크게 향상됩니다.

더 간단하고 안정적이므로 화이트리스트 접근 방식을 사용하는 것이 좋습니다. 잠재적으로 위험한 시스템 호출(또는 블랙리스트에 있는 경우 위험한 플래그/옵션)이 추가될 때마다 블랙리스트를 업데이트해야 합니다. 또한 매개변수의 본질을 변경하지 않고도 매개변수의 표현을 변경하여 블랙리스트의 제한을 우회하는 것이 가능한 경우가 많습니다.

Go 애플리케이션의 경우 애플리케이션과 함께 실행 중 발생하는 모든 호출을 수집하는 특수 도구를 개발했습니다. 예를 들어, 다음 애플리케이션의 경우:

package main

import "fmt"

func main() {
	fmt.Println("test")
}

... 발사하자 gosystract 다음과 같습니다 :

go install https://github.com/pjbgf/gosystract
gosystract --template='{{- range . }}{{printf ""%s",n" .Name}}{{- end}}' application-path

...그리고 우리는 다음과 같은 결과를 얻습니다:

"sched_yield",
"futex",
"write",
"mmap",
"exit_group",
"madvise",
"rt_sigprocmask",
"getpid",
"gettid",
"tgkill",
"rt_sigaction",
"read",
"getpgrp",
"arch_prctl",

지금은 이는 단지 예시일 뿐이며 도구에 대한 자세한 내용은 다음에 설명하겠습니다.

팁 # 6: 꼭 필요한 통화만 허용하고 다른 통화는 모두 차단하세요.

7. 올바른 기반 마련(또는 예상치 못한 행동에 대비)

커널은 사용자가 작성한 내용에 관계없이 프로필을 적용합니다. 꼭 원하는 것이 아니더라도 말이죠. 예를 들어 다음과 같은 호출에 대한 액세스를 차단하는 경우 exit 또는 exit_group, 컨테이너는 올바르게 종료할 수 없으며 다음과 같은 간단한 명령도 종료할 수 없습니다. echo hi 그를 끊다o 무기한. 결과적으로 클러스터에서 CPU 사용량이 높아집니다.

이러한 경우 유틸리티가 구출될 수 있습니다. strace - 문제가 무엇인지 표시됩니다.

sudo strace -c -p 9331

프로필에 런타임 시 애플리케이션에 필요한 모든 시스템 호출이 포함되어 있는지 확인하세요.

팁 # 7: 세부 사항에 주의를 기울이고 필요한 모든 시스템 호출이 허용 목록에 있는지 확인하세요.

이것으로 SecDevOps의 정신에 따라 Kubernetes에서 seccomp를 사용하는 방법에 대한 일련의 기사 중 첫 번째 부분을 마칩니다. 다음 부분에서는 이것이 중요한 이유와 프로세스를 자동화하는 방법에 대해 설명합니다.

번역가의 추신

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

• «Docker 컨테이너 보안";
• «33개 이상의 Kubernetes 보안 도구";
• «보안에 민감한 환경의 Docker 및 Kubernetes";
• «9 Kubernetes 보안 모범 사례".

출처 : habr.com