170-174. Image Security, Security Contexts

Docker(OCI) 컨테이너에서, 기본적으로 이미지 파일명 컨벤션은

• image: domain.name/username/imagename:version이다.

만약 image:nginx라고 간단하게 적었다면, 이것은 image: docker.io/library/nginx:latest로 해석된다.

• library는 Docker의 기본 사용자명이다.

로그인을 해야 쓸 수 있는 Private Registry가 존재한다.

• 대부분의 클라우드 프로바이더에서는 Private Registry 서비스를 제공한다.
• docker.io, gchr.io같은 퍼블릭 레지스트리에도 로그인해야 사용할 수 있는 Private Repo들이 존재한다.

하지만 Kubernetes에서 어떻게 프라이빗 레지스트리에 로그인을 할 수 있는가?

• docker-registry라는 타입에 이름은 regcred으로 하여 Secret을 생성한다.

  # kubectl create secret --help
  Create a secret with specified type.
  
  A docker-registry type secret is for accessing a container registry.
  
  A generic type secret indicate an Opaque secret type.
  
  A tls type secret holds TLS certificate and its associated key.

• 이후 Pod definition의 spec.imagePullSecrets[].name에 regcred를 넣으면 된다.

Docker Security

컨테이너 속의 프로그램들은 컨테이너 외부와 동일한 리눅스 커널을 공유한다.
실제로 호스트에서 ps aux를 찍어 보면 컨테이너에 들어있는 프로그램들이 보인다.

• 하지만, 컨테이너와 컨테이너 외부는 namespace를 통해 분리되며, 컨테이너 내부의 프로그램들은 그 namespace 외부를 볼 수 없다.
  • 컨테이너 내부에서 ps aux를 찍어 보면, CMD로 돌아가고 있는 프로세스가 PID 1로 되어 있을 것이다.
  • 호스트에서 ps aux를 찍어 보면, 컨테이너에서 돌고 있는 프로세스가 보이되 PID가 전혀 다르게 되어 있다.
    • 같은 프로세스라도 다른 네임스페이스에서는 다른 PID를 가지고 있을 수 있다.

기본적으로, Docker에서는 컨테이너를 root 사용자로 구동한다.

• Dockerfile에 USER uid를 지정하거나 Docker 커맨드라인에 --user=uid를 주어 커스텀이 가능하다.
• 컨테이너에 root를 주는 건 위험하지 않은가?
  • 기본적으로 docker는 Capability 제한을 걸어서 컨테이너 내부의 root가 sys_admin 따위의 권한을 가지지 않도록 한다.
  • privileged 플래그를 주면 모든 root권한을 주는 것도 가능은 하다.

Kubernetes Security

쿠버에서도 도커처럼 PID 설정, Capability 제한이 가능하다.

• Pod 단위 설정, Container 단위 설정이 모두 가능하며, Container 단위 설정이 Pod 설정에 우선한다.
  • Capability 설정은 컨테이너 단위에서만 가능하다.

spec:
  securityContext:
    runAsUser: 1000
containers:
- image: ubuntu
  name: ubuntu
  securityContext:
    capabilities:
      add: ["MAC_ADMIN"]