LXC는 잘 알려져 있고 철저한 테스트를 거친 저수준 Linux 컨테이너 런타임입니다. 2008년부터 활발히 개발 중이며 전 세계의 중요한 생산 환경에서 그 성능이 입증되었습니다. 핵심 기여자 중 일부는 Linux 커널 내에서 잘 알려진 다양한 컨테이너화 기능을 구현하는 데 도움을 준 사람들입니다.
유형 | 서비스 | 상태 |
---|---|---|
CI(리눅스) | GitHub | |
CI(리눅스) | 젠킨스 | |
프로젝트 현황 | CII 모범 사례 | |
퍼징 | OSS-퍼즈 | |
퍼징 | CI퍼즈 |
LXC의 주요 초점은 시스템 컨테이너입니다. 즉, VM에서 얻을 수 있는 것과 최대한 가까운 환경을 제공하지만 별도의 커널을 실행하고 모든 하드웨어를 시뮬레이션하는 데 따른 오버헤드가 없는 컨테이너입니다.
이는 네임스페이스, 필수 액세스 제어 및 제어 그룹과 같은 커널 보안 기능의 조합을 통해 달성됩니다.
권한이 없는 컨테이너는 권한 없이 실행되는 컨테이너입니다. 이를 위해서는 컨테이너가 실행되는 커널의 사용자 네임스페이스에 대한 지원이 필요합니다. LXC는 사용자 네임스페이스가 메인라인 커널에 병합된 후 권한이 없는 컨테이너를 지원하는 최초의 런타임이었습니다.
본질적으로 사용자 네임스페이스는 지정된 UID 및 GID 집합을 격리합니다. 이는 호스트의 UID 및 GID 범위와 컨테이너의 다른(권한 없는) UID 및 GID 범위 간의 매핑을 설정함으로써 달성됩니다. 커널은 컨테이너 내부에서 모든 UID 및 GID가 호스트에서 예상한 대로 표시되는 반면 호스트에서는 이러한 UID 및 GID가 실제로 권한이 없는 방식으로 이 매핑을 변환합니다. 예를 들어 컨테이너 내에서 UID 및 GID 0으로 실행되는 프로세스는 호스트에서 UID 및 GID 100000으로 나타날 수 있습니다. 구현 및 작업 세부 정보는 해당 사용자 네임스페이스 매뉴얼 페이지에서 수집할 수 있습니다.
권한이 없는 컨테이너는 보안 강화 기능이므로 자연스럽게 커널에 의해 시행되는 몇 가지 제한 사항이 적용됩니다. 완전한 기능을 갖춘 비특권 컨테이너를 제공하기 위해 LXC는 세 가지 setuid 코드와 상호 작용합니다.
다른 모든 것은 자신의 사용자 또는 사용자가 소유한 uid로 실행됩니다.
일반적으로 LXC의 목표는 커널에서 사용 가능한 모든 보안 기능을 활용하는 것입니다. 이는 LXC의 구성 관리를 통해 숙련된 사용자가 자신의 필요에 맞게 LXC를 복잡하게 조정할 수 있음을 의미합니다.
LXC 보안에 대한 자세한 소개는 다음 링크에서 확인하실 수 있습니다.
원칙적으로 LXC는 올바른 구성이 적용되면 이러한 도구 없이 실행될 수 있습니다. 그러나 이러한 컨테이너의 유용성은 일반적으로 매우 제한적입니다. 가장 일반적인 두 가지 문제를 강조하자면 다음과 같습니다.
네트워크: 권한이 없는 사용자를 위해 적절한 네트워크 장치를 설정하기 위해 setuid 도우미에 의존하지 않고(LXC의 lxc-user-nic
바이너리 참조) 유일한 옵션은 호스트와 네트워크 네임스페이스를 공유하는 것입니다. 이는 원칙적으로 안전해야 하지만 호스트의 네트워크 네임스페이스를 공유하는 것은 여전히 격리의 한 단계이며 공격 벡터를 증가시킵니다. 또한 호스트와 컨테이너가 동일한 네트워크 네임스페이스를 공유하는 경우 커널은 sysfs 마운트를 거부합니다. 이는 일반적으로 컨테이너 내부의 init 바이너리가 올바르게 부팅될 수 없음을 의미합니다.
사용자 네임스페이스: 위에서 설명한 대로 사용자 네임스페이스는 보안을 크게 향상시킵니다. 그러나 권한 있는 도우미에 의존하지 않고 호스트에서 권한이 없는 사용자는 자신의 UID를 컨테이너에 매핑하는 것만 허용됩니다. 그러나 표준 POSIX 시스템에서는 전체 기능을 보장하기 위해 65536개의 UID 및 GID를 사용할 수 있어야 합니다.
LXC는 간단한 키 세트를 통해 구성됩니다. 예를 들어,
lxc.rootfs.path
lxc.mount.entry
LXC는 단일 점을 사용하여 구성 키의 네임스페이스를 지정합니다. 이는 lxc.net.0
과 같은 복잡한 구성 키가 lxc.net.0.type
, lxc.net.0.link
, lxc.net.0.ipv6.address
등과 같은 다양한 하위 키를 노출한다는 것을 의미합니다. 세분화된 구성.
LXC는 잘 설계되고 안정적인 REST-API를 그 위에 노출하는 컨테이너 하이퍼바이저인 Incus의 기본 런타임으로 사용됩니다.
LXC는 2.6.32 이후의 모든 커널에서 실행됩니다. 필요한 것은 기능적인 C 컴파일러뿐입니다. LXC는 필요한 커널 기능을 제공하는 모든 아키텍처에서 작동합니다. 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.
LXC는 최소한 다음 C 표준 라이브러리도 지원합니다.
LXC는 항상 강력한 하위 호환성에 중점을 두었습니다. 실제로 API는 릴리스 1.0.0
부터 중단되지 않았습니다. 메인 LXC는 현재 버전 4.*.*
입니다.
LXC 프로젝트는 보안 문제를 빠르고 효율적으로 처리하는 것으로 좋은 평판을 얻고 있습니다. 잠재적인 보안 문제를 발견했다고 생각되면 security (at) linuxcontainers (dot) org에 이메일로 보고해 주십시오.
자세한 내용은 다음을 참조하세요.
우리는 항상 새로운 기여자를 환영하며 필요한 경우 기꺼이 지침을 제공합니다. LXC는 커널 코딩 규칙을 따릅니다. 이는 각 커밋에 Signed-off-by
라인만 포함하면 된다는 의미입니다. 우리가 사용하는 코딩 스타일은 Linux 커널에서 사용하는 것과 동일합니다. 자세한 소개는 다음에서 확인할 수 있습니다.
또한 이 저장소에 있는 CONTRIBUTING 파일도 살펴봐야 합니다.
좀 더 활동적으로 활동하고 싶다면 irc.libera.chat의 LXC IRC 채널 #lxc-dev에 참여하는 것도 좋은 생각입니다. 우리는 모든 개발을 공개적으로 수행하려고 노력하며 새로운 기능이나 버그에 대한 논의는 적절한 GitHub 문제나 IRC에서 이루어집니다.
보안에 중요한 기여나 실질적인 변경을 고려할 때 일반적으로 개발자에게 먼저 핑을 보내고 PR이 허용되는지 물어보는 것이 좋습니다.
LXC 및 관련 프로젝트는 의미론적 버전 관리 체계를 엄격하게 준수합니다.
최신 릴리스 버전의 소스는 언제든지 다음에서 다운로드할 수 있습니다.
온라인에서 최신 소스 코드와 변경 내역을 찾아볼 수 있습니다.
배포별 세부 사항을 고려하지 않고 간단한
meson setup -Dprefix=/usr build
meson compile -C build
일반적으로 충분합니다.
도움이 필요하다고 판단되면 LXC 프로젝트는 몇 가지 옵션을 제공합니다.
우리는 다음에서 토론 포럼을 운영합니다.
지원을 받을 수 있는 곳.
irc.libera.chat의 #lxc에서 우리를 찾을 수 있습니다.
두 개의 LXC 메일링 리스트 아카이브 중 하나를 확인하고 관심이 있으면 등록할 수 있습니다.