자주 묻는 질문 DevSecOps

DevSecOps 사용과 관련된 자주 묻는 질문에 대한 답변을 확인해 보세요.

CI와 CC 파이프라인의 차이점은 무엇인가요?

CI와 CC 파이프라인에는 공통된 단계가 있다는 것을 알 수 있습니다. 실행되는 스캔과 검사의 성격과 세부 사항은 비슷합니다. 다음 표는 CI와 CC 파이프라인의 차이점을 설명합니다.

CI 및 CC 파이프라인의 차이점
CI 파이프라인 CC 파이프라인
CI 툴체인의 일부입니다. CC 툴체인의 일부입니다.
병합 요청이 master 브랜치에 병합된 후 트리거됩니다 수동으로 트리거하거나 배포 일정과 무관하게 미리 정의된 간격으로 트리거할 수 있습니다.
URL 와 애플리케이션 코드 저장소 세부 정보는 설치 과정의 일부로 입력됩니다. URL 의 애플리케이션과 애플리케이션 코드 저장소 세부 정보는 CC 툴체인이 구성되고 첫 번째 파이프라인 실행이 시작되기 전에 제공됩니다.
규정 준수 점검 중 다양한 스캔 및 점검의 일부로 생성되는 인시던트 이슈에는 기한이 없습니다. 규정 준수 점검 중 다양한 스캔 및 점검의 일부로 생성되는 인시던트 이슈에는 기한이 정해져 있습니다.
생성되는 인시던트 이슈는 빌드 중에 발견됩니다. 생성되는 인시던트 문제는 스테이징 또는 프로덕션 환경을 주기적으로 스캔하는 동안 발견됩니다.
summary.json 파일은 각 CI 파이프라인 실행이 끝날 때 생성되지 않습니다. summary.json 파일은 각 CI 파이프라인 실행이 끝날 때 생성되지 않습니다.
여기에는 애플리케이션 아티팩트 생성, 아티팩트 서명 및 개발 클러스터에 배포와 같은 단계가 포함됩니다. 그러면 CD 파이프라인에 대한 입력이 생성됩니다. 규정 준수 테스트에 필요한 스캔 및 검사만 실행합니다.

사용자가 파이프라인을 사용자 지정하려면 어떻게 해야 하나요?

파이프라인은 사용자 지정 스크립트를 사용하여 사용자 지정할 수 있습니다. 사용자 지정 스크립트는 채택자, 팀 및 사용자가 CI/CD 전략에 대한 사용자 지정 작업을 실행하기 위한 스크립트를 제공할 수 있는 파이프라인의 확장 지점입니다.

사용자 정의 스크립트는 파이프라인 스테이지를 제어합니다. (pipeline-config.yaml) 구성 파일을 사용하여 스테이지의 동작, 스크립트 내용 및 스크립트를 실행하는 기본 아티팩트를 구성할 수 있습니다. 파이프라인 단계에 대한 스크립트 및 구성은 .travis.yml 또는 Jenkinsfile 과 유사한 애플리케이션 리포지토리 또는 사용자 지정 리포지토리에서 로드됩니다.

자세한 내용은 사용자 지정 스크립트를 사용하여 파이프라인 사용자 지정하기 를 참조하세요.

s390x 및 Power 플랫폼용 멀티 아치 이미지 제한 사항

원파이프라인은 원파이프라인 구성 파일에서 runtimeClassName (런타임 프로필을 나타내는 문자열)을 사용하여 s390x 및 Power 플랫폼에 대한 기본 지원을 제공합니다. 하지만 이 기본 지원에는 몇 가지 제한 사항과 권장 사항이 있습니다:

  • 제한사항:
    • 이 기능은 v11 에서만 사용할 수 있습니다.
    • 파드 시작 시간이 x86 런타임 클래스보다 길다.
    • s390x 또는 Power 워크로드와 함께 podman을 사용해야 합니다. Docker 사용할 수 없습니다.
      • 사용자 스크립트가 docker 명령 대신 podman 명령으로 작동하도록 업데이트해야 합니다
      • 스테이지 이미지에 포드맨이 설치되어 있어야 합니다.
  • 권장 사항: x86 런타임 클래스 사용
    • 스캔하는 경우 다양한 스캔 도구 이미지가 다중 아치를 지원하지 않을 수 있습니다.
    • 이미지 서명은 다중 아치를 지원하지 않으므로 사용할 수 없습니다(작업 진행 중).

사용자 정의 다중 아키텍처 기본 이미지를 어떻게 구축할 수 있나요?

One Pipeline은 다음 플랫폼을 지원하는 공식 멀티 아키텍처 기본 이미지를 제공합니다:

  • linux/amd64
  • linux/ppc64le
  • linux/s390x

대부분의 사용 사례에서는 공식 기본 이미지를 직접 사용하는 것을 권장합니다:

icr.io/continuous-delivery/toolchains/devsecops/baseimage:<version>

애플리케이션에 추가적인 운영 체제 패키지, 언어 런타임 또는 기타 사용자 지정 종속성이 필요한 경우, CI 파이프라인의 일환으로 자체적인 다중 아키텍처 기반 이미지를 빌드할 수 있습니다.

build-artifact 단계에서 ‘ --platform ’ 옵션을 사용하여 Docker Buildx를 실행하세요:

docker buildx build \
  --platform linux/amd64,linux/ppc64le,linux/s390x \
  -t <registry>/<namespace>/<image>:<tag> \
  --push .

이를 통해 아키텍처별 이미지를 생성하고, 이를 단일 다중 아키텍처 이미지 매니페스트로 게시합니다. 컨테이너 런타임은 대상 플랫폼에 적합한 이미지를 자동으로 가져옵니다.

권장되는 접근 방식

  1. Dockerfile에서 ‘ FROM ’ 이미지로 One Pipeline 기본 이미지를 사용하십시오.
  2. 애플리케이션에 필요한 추가 패키지나 종속성만 추가하십시오.
  3. CI 파이프라인에서 Docker Buildx를 사용하여 이미지를 빌드하고 배포하세요.
  4. docker buildx imagetools inspect 또는 skopeo inspect 을 사용하여 게시된 이미지를 확인하십시오.

멀티 아키텍처 지원 및 제한 사항에 대한 자세한 내용은 ‘ s390x 및 Power 플랫폼용 멀티 아키텍처 이미지의 제한 사항 ’을 참조하십시오.

CLI를 사용하여 파이프라인 트리거하기

파이프라인은 IBM Cloud CLI 또는 API를 사용하여 트리거할 수 있습니다. CLI를 사용하면 툴체인과 파이프라인 ID를 제공하여 파이프라인을 시작할 수 있습니다. API를 사용하면 올바른 인증과 헤더가 포함된 POST 요청을 보내 파이프라인을 트리거할 수 있습니다.

자세한 내용은 트리거 사용을 참조하세요

Git 저장소를 복제할 때 어떤 환경 변수가 사용되나요?

DevSecOps 파이프라인은 계층적 토큰 시스템을 사용하여 복제(cloning)를 포함한 Git 저장소 작업에 대한 인증을 수행합니다. git-token 환경 속성은 기본 토큰으로 사용되지만, 보안 및 접근 제어를 강화하기 위해 더 구체적인 토큰으로 재정의할 수 있습니다.

토큰 우선순위 순서

파이프라인은 Git 인증 토큰을 다음 우선순위 순서(높은 순서부터 낮은 순서)로 처리합니다:

  1. 특정 저장소의 툴체인 통합에 지정된 개인 액세스 토큰(PAT)
  2. 저장소별 토큰: git-token-[repo_name]-[repo_org]
  3. 조직별 토큰: git-token-[repo_org]
  4. 기본 토큰: git-token
  5. OAuth 토큰 툴체인 통합 (PAT 대신 OAuth 를 사용하는 경우)

토큰 명명 예시

https://github.com/my-org/my-app 에 있는 저장소의 경우:

  • 저장소별: git-token-my-app-my-org
  • 조직별: git-token-my-org

중요한 고려사항

  • 리포지토리 읽기(클로닝)와 쓰기 작업(PR/CI 상태 설정, 인벤토리 업데이트) 모두에 동일한 git-token 를 사용하는 경우, 읽기 전용 액세스 권한만으로는 충분하지 않습니다. 토큰에는 쓰기 권한이 있어야 합니다.
  • 리포지토리 또는 조직 전용 토큰을 사용하면 각 리포지토리에 필요한 권한만 부여함으로써 최소 권한 원칙을 적용할 수 있습니다.

리포지토리 토큰 기능에 대한 자세한 내용은 ‘리포지토리 정보 및 토큰 가져오기’를 참조하세요.

OnePipeline 구성 변경 사항을 테스트하는 방법은 무엇인가요?

OnePipeline 구성 변경 사항을 테스트할 때는 사용자 지정 설정을 검증하는 과정에서 운영 파이프라인에 차질이 생기지 않도록 체계적인 접근 방식이 필요합니다.

OnePipeline 구성 요소 이해하기

OnePipeline 다음과 같은 두 가지 주요 사용자 정의 가능 구성 요소로 이루어져 있습니다:

  • Tekton 파이프라인 정의: PR, CI, CD 및 CC 워크플로를 위한 중앙 집중식 파이프라인 정의( compliance-pipelines 저장소에서 이용 가능). 새로운 버전은 2주마다 스프린트 주기로 출시됩니다.

    • v10: 동시 실행이 제한된 안정화 버전
    • v11: 최고의 사용자 정의 기능과 동시 처리 능력을 갖춘 차세대 버전

  • 파이프라인 구성 (.pipeline-config.yaml): 파이프라인 이미지, 스크립트, 아키텍처 및 속성을 포함하여 기본 파이프라인 동작을 재정의하는 사용자 지정 구성 파일입니다. 이 파일은 애플리케이션 저장소나 중앙 집중식 구성 저장소에 저장할 수 있습니다.

테스트 방법 1: 테스트 구성 파일 사용

이는 운영 파이프라인에 영향을 주지 않고 구성 변경 사항을 테스트하기 위한 권장 방법입니다.

  1. 테스트 브랜치 생성하기

    • .pipeline-config.yaml 파일이 포함된 저장소에 브랜치를 생성하세요
    • 이 브랜치에서 구성 변경 사항을 적용하세요

  2. 테스트 트리거 설정

    • 툴체인에 있는 기존 파이프라인 트리거를 복제하세요
    • 이름을 명확하게 지정하세요 (예: Manual-Test-Config)
    • 트리거 속성을 테스트 구성으로 가리키도록 업데이트하십시오:
      • pipeline-config: 구성 파일의 파일 이름
      • pipeline-config-branch: 테스트 브랜치 이름
      • pipeline-config-repo: 구성이 포함된 저장소 URL

  3. 개발 모드에서 테스트

    • 트리거 속성에서 개발 모드 활성화
    • 파이프라인을 실행하여 사용자 지정 스크립트를 검증하세요
    • 개발 모드는 증거 수집, 규정 준수 문제 생성 및 인벤토리 업데이트 단계를 생략하므로 신속한 반복 작업에 이상적입니다
    • 중요: 개발 모드는 운영 환경의 워크로드에는 적합하지 않습니다

  4. 규정 준수 점검을 포함한 테스트

    • 개발 모드에서 스크립트를 검증한 후, 비활성화하십시오 dev-mode
    • 테스트 중에는 재고 업데이트 기능을 비활성화해 두세요
    • 증거 수집 및 이슈 관리를 포함한 전체 파이프라인을 실행합니다
    • 모든 규정 준수 검사가 예상대로 통과되는지 확인하십시오

  5. 프로덕션으로 승격

    • 테스트 결과가 만족스러우면, 변경 사항을 메인 브랜치에 병합하기 위해 풀 리퀘스트를 생성하세요
    • 변경 사항은 프로덕션 트리거에 자동으로 적용됩니다
    • 문제가 발생하면 변경 사항을 즉시 원상복구할 수 있습니다

테스트 접근 방식 2: 파이프라인 레이아웃 수정

파이프라인 정의 분기 (고급)

  • ( compliance-pipelines 저장소를 포크하세요)
  • 포크에서 변경 사항을 개발하고 테스트하세요
  • 툴체인에 포크한 저장소를 ‘ Git ’ 통합으로 추가하세요
  • 포크를 참조하도록 파이프라인 정의를 일시적으로 업데이트하세요
  • 새로운 파이프라인 정의를 테스트하기 위해 개발 모드 트리거를 구성합니다
  • 방법 1의 테스트 단계를 따르십시오

우수 사례

  • 스크립트 오류를 신속하게 파악하려면 항상 먼저 개발 모드에서 테스트하십시오
  • 혼동을 피하기 위해 테스트 트리거에는 설명적인 이름을 사용하십시오
  • 구성 변경 사항을 커밋 메시지에 기록하세요
  • 실수로 테스트가 실행되는 것을 방지하려면 테스트 트리거를 비활성화 상태로 유지하거나 테스트가 끝난 후 삭제하십시오
  • 주요 파이프라인 변경 사항에 대비해 전용 테스트 툴체인을 구축하는 것을 고려해 보십시오
  • 파이프라인 로그를 꼼꼼히 검토하여 모든 단계가 예상대로 실행되는지 확인하십시오

파이프라인 사용자 지정에 대한 자세한 내용은 ‘사용자 정의 스크립트’ 및