17장. RHEL의 이미지 모드에서 사용자, 그룹, SSH 키 및 시크릿 관리
Red Hat Enterprise Linux의 이미지 모드에서 사용자, 그룹, SSH 키 및 시크릿을 관리하여 시스템 액세스를 제어할 수 있습니다. 이러한 인증 정보를 구성하면 컨테이너 네이티브 운영 체제 배포에 대한 보안 인증 및 권한 부여 정책을 설정할 수 있습니다.
17.1. 사용자 및 그룹 구성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Enterprise Linux bootc 이미지의 사용자 및 그룹을 구성하여 시스템 액세스 제어 및 관리 권한을 설정합니다. 이미지 빌드 중에 이러한 설정을 정의하면 해당 이미지에서 파생된 모든 배포에서 일관된 인증 정책이 보장됩니다.
- 일반 기본 이미지에 대한 사용자 및 그룹 구성
- 일반적으로 배포 기본 이미지에 구성이 없습니다. 보안 위험으로 인해 일반 이미지에서 공개적으로 사용 가능한 개인 키를 사용하여 암호 및 SSH 키를 암호화하지 마십시오.
systemd자격 증명을 통해 SSH 키 삽입-
systemd를 사용하여 일부 환경에서 root 암호 또는 SSHauthorized_keys파일을 삽입할 수 있습니다. 예를 들어SMBIOS(System Management 펌웨어)를 사용하여 SSH 키 시스템 펌웨어를 삽입합니다.qemu와 같은 로컬 가상화 환경에서 이를 구성할 수 있습니다. cloud-init를 사용하여 사용자 및 SSH 키 삽입-
많은 Infrastructure as a Service( Infrastructure as a Service) 및 가상화 시스템은
cloud-init또는ignition과 같은 소프트웨어에서 일반적으로 처리되는 메타데이터 서버를 사용합니다. AWS 인스턴스 메타데이터 를 참조하십시오. 사용 중인 기본 이미지에cloud-init또는 Ignition이 포함되어 있거나 자체 파생 이미지에 설치할 수 있습니다. 이 모델에서 SSH 구성은 bootc 이미지 외부에서 관리됩니다. - 컨테이너 또는 단위 사용자 지정 논리를 사용하여 사용자 및 인증 정보 추가
-
cloud-init와 같은 시스템은 권한이 없습니다. 예를 들어systemd장치를 사용하여 컨테이너 이미지를 시작하려는 방식으로 자격 증명을 관리하려는 논리를 삽입할 수 있습니다. 자격 증명을 관리하려면 사용자 지정 네트워크 호스팅 소스(예: FreeIPA )를 사용할 수 있습니다. - 컨테이너 빌드에서 정적으로 사용자 및 인증 정보 추가
패키지 지향 시스템에서는 파생 빌드를 사용하여 다음 명령을 사용하여 사용자 및 인증 정보를 삽입할 수 있습니다.
RUN useradd someuseruseradd: 사용자 및 그룹 ID의 기본shadow-utils구현에서 문제를 찾을 수 있으며 이로 인해 드리프트가 발생할 수 있습니다.- 사용자 및 그룹 홈 디렉토리 및
/var디렉토리 영구
/home으로 구성된 시스템의 경우 초기 설치 후 컨테이너 이미지에서 만든/var/home /var변경 사항은 후속 업데이트에 적용되지 않습니다.예를 들어
/var/home/someuser/.ssh/authorized_keys를 컨테이너 빌드에 삽입하면 기존 시스템에는 업데이트된authorized_keys파일이 제공되지 않습니다.systemd장치에 DynamicUser=yes 사용시스템 사용자에게 가능한 경우
systemdDynamicUser=yes옵션을 사용합니다.이는 잠재적인 UID 또는 GID 드리프트가 방지되므로 패키지 설치 시 사용자 또는 그룹을 할당하는 패턴보다 훨씬 우수합니다.
nss-altfiles사용nss-altfiles는 시스템 사용자를/usr/lib/passwd및/usr/lib/group으로 분할하여 OSTree 프로젝트가/etc/passwd와 관련하여/etc에 대해 병합하는 방법과 정렬합니다. 현재/etc/passwd파일이 로컬 시스템에서 어떤 방식으로든 수정되면 컨테이너 이미지의/etc/passwd에 대한 변경 사항이 적용되지 않습니다.rpm-ostree로 빌드된 기본 이미지에는 기본적으로nss-altfiles가 활성화되어 있습니다.또한 기본 이미지에는 UID 또는 GID 드리프트를 방지하기 위해 NSS 파일에서 사전 할당 및 관리하는 시스템 사용자가 있습니다.
파생 컨테이너 빌드에서는 사용자를
/usr/lib/passwd에 추가할 수도 있습니다. 예를 들면 다음과 같습니다.sysusers.d또는DynamicUser=yes를 사용합니다.systemd-sysusers 사용예를 들어, 파생 빌드에서
systemd-sysusers를 사용합니다. 자세한 내용은systemd-sysusers 설명서를 참조하십시오.COPY mycustom-user.conf /usr/lib/sysusers.dsysusers툴은 부팅 시 필요에 따라 기존/etc/passwd파일을 변경합니다./etc가 영구적인 경우UID또는GID드리프트를 방지할 수 있습니다. 즉UID또는GID할당은 시간이 지남에 따라 특정 시스템을 업그레이드하는 방법에 따라 달라집니다.- 사용자의 머신 로컬 상태
파일 시스템 레이아웃은 기본 이미지에 따라 다릅니다.
기본적으로 사용자 데이터는 기본 이미지에 따라
/etc,/etc/passwd,/etc/shadow및groups,/home모두에 저장됩니다. 그러나 일반 기본 이미지는 둘 다 machine-local 영구 상태여야 합니다. 이 모델에서/home은 /var/home/사용자에대한 심볼릭 링크입니다.- 시스템 프로비저닝 시 사용자 및 SSH 키 삽입
/etc및/var가 기본적으로 유지되도록 구성된 기본 이미지의 경우 Anaconda 또는 Kickstart와 같은 설치 프로그램을 사용하여 사용자를 삽입할 수 있습니다.일반적으로 일반 설치 프로그램은 한 번만 부트스트랩하도록 설계되었습니다. 그런 다음 구성은 다른 메커니즘을 사용하여 Day 2 작업에서 변경할 수 있는 변경 가능한 머신 로컬 상태가 됩니다.
Anaconda 설치 프로그램을 사용하여 초기 암호를 설정할 수 있습니다. 그러나 이 초기 암호를 변경하려면
passwd와 같은 다른 시스템 내 툴이 필요합니다.이러한 흐름은 다양한 시스템 내 툴을 변경할 필요 없이 일반 기본 이미지를 직접 설치할 수 있도록
bootc 호환시스템에서도 동일하게 작동합니다.- 임시 홈 디렉토리
많은 운영 체제 배포로 영구, 변경 가능 및 실행 가능한 상태가 최소화됩니다. 이로 인해 사용자 홈 디렉터리가 손상될 수 있습니다.
/home디렉토리는 재부팅 시 사용자 데이터가 지워지도록tmpfs로 설정할 수 있습니다. 이 접근 방식은 일시적인/etc디렉토리와 결합되는 경우 특히 잘 작동합니다.예를 들어 SSH
authorized_keys또는 기타 파일을 삽입하도록 사용자의 홈 디렉터리를 구성하려면systemdtmpfiles.d스니펫을 사용합니다.f~ /home/user/.ssh/authorized_keys 600 user user - <base64 encoded data>SSH는 /
usr/lib/tmpfiles.d/<username-keys.conf로 이미지에 포함됩니다. 또 다른 예로는 네트워크에서 키를 가져와 쓸 수 있는 이미지에 포함된 서비스가 있습니다. 이는cloud-init에서 사용하는 패턴입니다.- UID 및 GID 드리프트
-
/etc/passwd및 유사한 파일은 이름과 숫자 식별자 간의 매핑입니다. 매핑이 동적이고 "상태리스" 컨테이너 이미지 빌드와 혼합되면 문제가 발생할 수 있습니다. 각 컨테이너 이미지 빌드는 RPM 설치 순서 또는 기타 이유로 인해 UID가 변경될 수 있습니다. 이 문제는 해당 사용자가 영구 상태를 유지 관리하는 경우 문제가 될 수 있습니다. 이러한 경우를 처리하려면sysusers.d를 사용하거나DynamicUser=yes를 사용하도록 변환합니다.