2.8. 빌드 프로세스 보안
컨테이너 환경에서 소프트웨어 빌드 프로세스는 애플리케이션 코드가 필수 런타임 라이브러리와 통합되는 라이프사이클의 단계입니다. 이 빌드 프로세스 관리는 소프트웨어 스택을 보호하는 데 핵심입니다.
2.8.1. 한 번 빌드하여 어디에나 배포
컨테이너 빌드를 위한 표준 플랫폼으로 OpenShift Container Platform을 사용하면 빌드 환경의 보안을 보장할 수 있습니다. "한 번만 빌드하여 어디에나 배포" 철학을 준수하면 빌드 프로세스의 제품을 프로덕션에 정확히 배포할 수 있습니다.
컨테이너의 불변성을 유지 관리하는 것도 중요합니다. 실행 중인 컨테이너에 패치를 적용하지 말고 다시 빌드하여 재배치해야 합니다.
소프트웨어가 빌드, 테스트 및 프로덕션 단계를 진행해 갈 때 소프트웨어 공급망을 구성하는 툴을 신뢰하는 것이 중요합니다. 다음 그림에서는 컨테이너화된 소프트웨어를 위한 신뢰할 수 있는 소프트웨어 공급망에 통합될 수 있는 프로세스와 툴을 보여줍니다.
OpenShift Container Platform은 신뢰할 수 있는 코드 리포지토리(예: GitHub) 및 개발 플랫폼(예: Che)과 통합되어 보안 코드를 생성하고 관리할 수 있습니다. 단위 테스트에서는 Cucumber 및 JUnit을 사용합니다. 컨테이너에서 Anchore 또는 Twistlock의 취약점 및 컴플라이언스 문제가 있는지 검사하고 AtomicScan 또는 Clair와 같은 이미지 검색 툴을 사용할 수 있습니다. Sysdig와 같은 툴을 사용하면 컨테이너화된 애플리케이션을 지속적으로 모니터링할 수 있습니다.
2.8.2. 빌드 관리
S2I(Source-to-Image)를 사용하여 소스 코드와 기본 이미지를 결합할 수 있습니다. 빌더 이미지는 S2I를 사용하므로 개발 및 운영 팀이 재현 가능한 빌드 환경에서 협업할 수 있습니다. UBI(Universal Base Image) 이미지로 사용 가능한 Red Hat S2I 이미지를 사용하면 실제 RHEL RPM 패키지에서 빌드된 기본 이미지로 소프트웨어를 자유롭게 재배포할 수 있습니다. Red Hat에서는 이를 허용하기 위해 서브스크립션 제한 사항을 제거했습니다.
개발자가 빌드 이미지를 사용하여 애플리케이션용 Git로 코드를 커밋하면 OpenShift Container Platform에서는 다음 기능을 수행할 수 있습니다.
- 사용 가능한 아티팩트, S2I 빌더 이미지 및 새로 커밋된 코드에서 자동으로 새 이미지를 어셈블링하기 위해 코드 리포지토리의 웹 후크를 사용하거나 기타 자동 연속 통합(CI) 프로세스를 사용하여 트리거합니다.
- 테스트를 위해 새로 빌드된 이미지를 자동으로 배포합니다.
- 테스트된 이미지를 CI 프로세스를 사용하여 자동으로 배포할 수 있는 프로덕션으로 승격합니다.
통합 OpenShift Container Registry를 사용하여 최종 이미지에 대한 액세스를 관리할 수 있습니다. S2I 및 기본 빌드 이미지가 자동으로 OpenShift Container Registry로 푸시됩니다.
포함된 Jenkins for CI 외에도 RESTful API를 사용하여 자체 빌드 및 CI 환경을 OpenShift Container Platform과 통합하고 API 호환 이미지 레지스트리를 사용할 수 있습니다.
2.8.3. 빌드 중 입력 보안
일부 시나리오에서는 빌드 작업을 할 때 종속 리소스에 액세스하기 위한 인증서가 필요하지만 빌드에서 생성한 최종 애플리케이션 이미지에서 해당 인증서가 사용 가능한 것은 바람직하지 않습니다. 이 목적을 위해 입력 보안을 정의할 수 있습니다.
예를 들어 Node.js 애플리케이션을 빌드할 때 Node.js 모듈에 맞게 개인용 미러를 설정할 수 있습니다. 이 개인용 미러에서 모듈을 다운로드하려면 URL, 사용자 이름 및 암호가 포함된 빌드에 사용할 사용자 정의 .npmrc 파일을 제공해야 합니다. 보안상의 이유로 애플리케이션 이미지에 자격 증명을 노출해서는 안 됩니다.
이 예제 시나리오를 사용하여 새 BuildConfig 오브젝트에 입력 보안을 추가할 수 있습니다.
보안이 없으면 다음과 같이 생성합니다.
$ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc
그러면
~/.npmrc파일의 base64 인코딩 콘텐츠를 포함하는secret-npmrc라는 새 보안이 생성됩니다.다음과 같이 기존
BuildConfig오브젝트의source섹션에 보안을 추가합니다.source: git: uri: https://github.com/sclorg/nodejs-ex.git secrets: - destinationDir: . secret: name: secret-npmrc새
BuildConfig오브젝트에 보안을 포함하려면 다음 명령을 실행합니다.$ oc new-build \ openshift/nodejs-010-centos7~https://github.com/sclorg/nodejs-ex.git \ --build-secret secret-npmrc
2.8.4. 빌드 프로세스 설계
개별적으로 제어할 수 있도록 컨테이너 이미지 관리를 설계하고 컨테이너 계층을 사용하도록 프로세스를 구축할 수 있습니다.
예를 들어, 운영 팀은 기본 이미지를 관리하는 반면 아키텍트는 미들웨어, 런타임, 데이터베이스 및 기타 솔루션을 관리합니다. 그런 다음 개발자는 애플리케이션 계층과 코드 작성에 중점을 둘 수 있습니다.
매일 새로운 취약점이 식별되므로 시간 경과에 따라 컨테이너 콘텐츠를 사전 대응식으로 확인해야 합니다. 이를 위해서는 자동화된 보안 테스트를 빌드 또는 CI 프로세스에 통합해야 합니다. 예를 들면 다음과 같습니다.
- SAST/DAST – 정적 및 동적 보안 테스트 도구.
- 알려진 취약점과 비교하여 실시간 검사를 위한 스캐너. 이러한 툴을 통해서는 컨테이너의 오픈소스 패키지를 카탈로그화하고 알려진 취약점을 사용자에게 알리며 이전에 스캔한 패키지에서 새로운 취약점이 발견되면 사용자에게 이 내용을 업데이트합니다.
CI 프로세스에는 보안 스캔에서 발견된 문제로 빌드에 플래그를 표시하는 정책이 포함되어 있으므로, 팀이 해당 문제를 해결하기 위해 적절한 조치를 취할 수 있습니다. 빌드와 배포 사이에 아무것도 변경되지 않도록 사용자 정의 빌드 컨테이너에 서명해야 합니다.
GitOps 방법론을 사용하면 동일한 CI/CD 메커니즘을 사용하여 애플리케이션 구성뿐만 아니라 OpenShift Container Platform 인프라를 관리할 수 있습니다.
2.8.5. Knative 서버리스 애플리케이션 빌드
Kubernetes 및 Kourier를 사용하면 OpenShift Container Platform에서 OpenShift Serverless를 사용하여 서버리스 애플리케이션을 빌드, 배포, 관리할 수 있습니다.
다른 빌드와 마찬가지로 S2I 이미지를 사용하여 컨테이너를 빌드한 다음 Knative 서비스를 사용하여 컨테이너를 제공할 수 있습니다. OpenShift Container Platform 웹 콘솔의 토폴로지 보기를 통해 Knative 애플리케이션 빌드를 봅니다.
