추론된 DevSecOps 구성으로 파이프라인 만들기
DevSecOps 지속적 통합(CI) 툴체인에 자체 애플리케이션이나 마이크로서비스를 추가한 후에는 ‘추론된 DevSecOps 파이프라인 구성’ 기능을 활용하여 신속하게 작업을 시작할 수 있습니다. 이 기능:
- '
.pipeline-config.yamlDevSecOps 파이프라인 구성 파일의 내용을 추론합니다 - 코드를 빌드, 테스트 및 배포하는 데 필요한 스크립트를 식별합니다
- 이러한 스크립트에 대한 코드를 제공하므로 애플리케이션에 집중할 수 있습니다
이 기능을 사용하면 마이크로서비스나 애플리케이션을 DevSecOps 파이프라인에 손쉽게 온보딩하고 도입 과정을 DevSecOps 간소화할 수 있습니다.
추론 DevSecOps 파이프라인 구성을 설정하기 위한 추가 단계는 필요하지 않습니다. 이미 DevSecOps 통합되어 있기 때문입니다.
DevSecOps 연속 배포(CD) 툴체인에도 기본 파이프라인 구성이 포함되어 있습니다. 이를 통해 CI 환경에서 Inferred DevSecOps 구성 기능을 사용하는 사용자는 동일한 방식을 CD 파이프라인으로 안전하게 확장할 수 있습니다. 배포 작업은 인벤토리 항목의 app_artifacts 메타데이터를 기반으로 결정됩니다.
DevSecOps 지속적 준수(CC) 툴체인 역시 추론된 준수 관리( DevSecOps ) 구성의 이점을 누릴 수 있습니다. 파이프라인 구성은 인벤토리 항목에 포함된 리포지토리의 내용을 바탕으로 추론됩니다.
전제조건
-
DevSecOps 툴체인을 설정하고 애플리케이션의 소스 코드 리포지토리를 통합하세요.
기본 샘플 앱 리포지토리를 사용하지 마세요. 대신 자체 애플리케이션의 리포지토리를 온보딩하세요.
-
사용 가능한 다양한 템플릿, 지원 옵션 및 기타 중요한 정보에 대해 자세히 알아보려면 DevSecOps 파이프라인 사용자 지정의 기본 사항을 검토하여 DevSecOps 시작하는 데 도움이 되는 정보를 확인하세요.
시작하기
시작하려면 자체 소스 코드 리포지토리를 사용하도록 툴체인을 구성하세요. 그런 다음 첫 번째 DevSecOps CI 파이프라인을 실행합니다. 이 기능은 기본적으로 활성화되어 있으므로 추가 설정이 필요하지 않습니다. 애플리케이션 또는 서비스를 빌드, 테스트 및 배포하는 데 필요한 DevSecOps 파이프라인 구성 및 스크립트를 동적으로 추론합니다.
이 기능을 비활성화하려면 리포지토리에 있는 기존 파일과 일치하는 ' pipeline-config ' 값을 설정하세요.
추론된 DevSecOps 파이프라인 구성이 있는 지점
추론된 DevSecOps 파이프라인 구성 기능은 소스 인트로스펙션 및 언어 정의를 사용하여 소스 리포지토리에서 ' spots '를 식별합니다. ' spot '은 코드에서 특정 작업을 수행해야 하는 위치입니다.
각 스팟에는 다음과 같은 속성이 있습니다:
| 특성 | 설명 |
|---|---|
| 소스 | 소스 코드 리포지토리의 위치를 해당 지점의 컨텍스트로 식별합니다. |
| 프로세스 | 수행할 작업 유형을 나타내는 하나 이상의 프로세스입니다. |
| 도구 | 작업을 수행하기 위해 시작할 도구를 나열하는 프로세스에 연결된 배열입니다. 각 도구에는 고유한 속성 집합이 있을 수 있습니다. |
| 환경 설정 | 프로세스 작업(도구 호출)이 수행될 환경을 설정하기 위해 시작될 스크립트 파일(또는 스크립트 명령)을 참조합니다. |
식별된 지점
추론된 DevSecOps 파이프라인 구성 기능은 현재 다음과 같은 유형의 ' spots'를 식별합니다:
code 스팟, ' deployment ' 스팟, ' acceptance-test ' 스팟, ' dynamic-scan ' 스팟 및 ' release' 스팟.
코드 스팟
코드 스팟은 다음을 포함하여 지원되는 소스 코드 언어와 관련이 있습니다:
- Node.js (npm, Yarn 또는 Gradle 사용)
- Java (Maven 또는 Gradle 사용)
- Golang
- Python
- Dockerfile
- Terraform 구성 언어
' code 스팟은 다음 프로세스를 처리합니다:
building' : 주어진 소스 코드의 빌드를 수행하는 도구를 정의합니다.unit-testing' : 빌드 결과의 단위 테스트를 수행하는 도구를 찾습니다.
배포 장소
' deployment 스팟은 배포 리소스 및 도구를 포함한 배포 수단을 찾습니다. deployment 스팟에는 배포 도구가 나열된 배포 프로세스가 있습니다. 현재 지원되는 배포 차량은 다음과 같습니다:
-
'
Pod, 'ReplicaSet' , 'ReplicationController' , 'Deployment' , 'Daemonset' , 'StatefulSet' , 'Job' , 'Cronjob' , 'NetworkPolicy' , 'Ingress' , 'Service' , 'Route' 같은 Kubernetes 리소스 정의 - 도구로서의 kubectl -
Helm 차트- 도구로서의 헬름
-
Terraform 구성- IBM Cloud Schematics 또는 도구로서의 Terraform CLI
-
IBM Cloud Code Engine 배포를 위해 구성된 경우 Dockerfile- 도구로서의 IBM Cloud Code Engine CLI
합격 시험 장소
' acceptance-test 스팟은 실행할 수락 테스트 세트를 찾습니다. acceptance-test 스팟에는 수락 테스트 세트를 실행할 도구를 식별하는 ' acceptance-testing 프로세스가 있습니다.
동적 스캔 지점
' dynamic-scan 스팟은 동적 스캔을 위한 위치를 식별합니다. 동적 스캔 지점에는 동적 스캔 중에 호출되는 스캔 도구를 나열하는 ' scanning 프로세스가 있습니다.
하위 웹훅 트리거를 별표로 표시할 수 있는 유일한 지원 도구는 OWASP ZAP 스캔입니다.
릴리스 지점
' release 스팟은 릴리스 프로세스를 찾습니다. 릴리스 스팟에는 릴리스 단계에서 실행할 도구가 나열된 ' releasing 프로세스가 있습니다. 현재 릴리스 프로세스에 지원되는 도구는 다음과 같습니다:
- 시맨틱 릴리스
- '
maven deploy' 단계의 maven을 사용합니다.
polyglot-spots.json 콘텐츠 샘플
추론된 DevSecOps 파이프라인 구성 기능은 스팟을 추출하고 다음 JSON 콘텐츠를 생성하여 CI 파이프라인 단계 중에 특정 작업 및 도구를 트리거합니다.
{
"code": [
{
"source": "Dockerfile",
"language": "Dockerfile",
"building": {
"tools": [
{
"tool": "docker"
}
]
}
},
{
"source": "package.json",
"language": "NodeJS",
"building": {
"tools": [
{
"tool": "npm"
}
]
},
"unit-testing": {
"tools": [
{
"tool": "npm",
"command": "test"
}
]
}
}
],
"acceptance-test": [
{
"source": "package.json",
"acceptance-testing": {
"tools": [
{
"tool": "npm",
"command": "run acceptance-test"
}
]
}
}
],
"deployment": [
{
"source": "deployment_iks.yml",
"deploying": {
"tools": [
{
"tool": "kubectl"
}
],
"environment-setup": ".env.deploy.sh"
}
},
{
"source": "deployment_os.yml",
"deploying": {
"tools": [
{
"tool": "kubectl"
}
],
"environment-setup": ".env.deploy.sh"
}
}
],
"dynamic-scan": [
{
"source": "definitions/definitions1.json",
"scanning": {
"tools": [
{
"tool": "trigger-async-zap",
"kind": "api"
}
],
"environment-setup": "scripts/zap/zap-custom-scripts/.env.dynamic-scan.sh"
}
},
{
"source": "scripts/zap/uiscripts/run.sh",
"scanning": {
"tools": [
{
"tool": "trigger-async-zap",
"kind": "ui"
}
],
"environment-setup": "scripts/zap/zap-custom-scripts/.env.dynamic-scan.sh"
}
}
],
"release": []
}
고급 구성
파일 삽입
추론된 DevSecOps 파이프라인 구성 기능은 ' polyglot-spots.json ' 및 ' .pipeline-config.yaml ' 파일의 내용을 사용하여 DevSecOps 파이프라인 프로세스 실행을 사용자 지정합니다.
CI 파이프라인의 ' finish 단계에서 ' polyglot-spots.json '와 ' .pipeline-config.yaml '(CI 파이프라인 실행의 정적 파이프라인 구성에 해당)은 모두 애플리케이션 소스 코드 리포지토리의 ' inferred-devsecops '(기본값)라는 브랜치에 추가됩니다.
2 (예: v11 의 compliance-pipelines 브랜치에서 사용 가능) 형식의 파이프라인 구성은 create-inferred-pipeline-configuration-v2 속성이 true (기본값: false )로 설정되어 있는 경우에도 생성할 수 있습니다. .pipeline-config-v2.yaml 와 같은 추가 파이프라인 구성 파일이 애플리케이션 소스 코드 저장소의 inferred-devsecops (기본값)라는 분기에 추가됩니다.
인젝션 브랜치 구성
' inferred-devsecops-branch 파이프라인 속성을 사용하여 DevSecOps 추론 파일을 삽입할 브랜치 이름을 구성할 수 있습니다. 기본값은 inferred-devsecops입니다.
push-inferred-pipeline-configuration-files 파이프라인 속성( push-polyglot-files 속성은 push-inferred-pipeline-configuration-files 속성으로 대체됨)을 사용하여 inferred-devsecops 브랜치의 생성 및 업데이트를 활성화하거나 비활성화합니다
| 값 | 설명 |
|---|---|
true(기본값) |
구성 파일이 추가되어 소스 애플리케이션 소스 코드 리포지토리의 ' inferred-devsecops ' 브랜치에 푸시됩니다. |
false |
구성 파일은 inferred-devsecops 브랜치에 추가되지 않습니다. |
스팟 추출 구성
다음 파이프라인 환경 속성을 사용하여 스팟 추출을 구성합니다:
스팟 무시
정규식을 사용하여 추출하는 동안 특정 지점을 무시할 수 있습니다. 다음 구성 옵션이 사용 가능합니다.
ignore-code-spot-pattern' : 지정된 정규식과 일치하는 코드 스폿을 무시합니다.ignore-deployment-spot-pattern' : 지정된 정규식과 일치하는 배포 지점을 무시합니다.ignore-dynamic-scan-spot-pattern' : 지정된 정규식과 일치하는 동적 스캔 지점을 무시합니다.ignore-acceptance-test-spot-pattern' : 지정된 정규식과 일치하는 허용 테스트 지점을 무시합니다.ignore-release-spot-pattern' : 지정된 정규식과 일치하는 릴리스 지점을 무시합니다.
Code Engine 구성
배포에 IBM Cloud Code Engine 을 사용하는 경우 Code Engine 프로젝트를 지정하고 다음 파이프라인 환경 속성을 사용하여 빌드 프로세스를 구성합니다:
code-engine-project' : Code Engine 프로젝트를 지정합니다.code-engine-build-use-native-docker: (기본값: 'false) 'ibmcloud code-engine buildrun' 명령 대신 Docker CLI를 사용할지 여부를 나타냅니다.code-engine-disable-buildpacks-strategy(기본값false) 빌드 프로세스가buildpacks전략을 사용해서는 안됨을 나타냅니다(code-engine-project이 설정된 경우에만 유효)root-as-build-context: (기본값:false)는Dockerfile관련 빌드 도구(docker또는code-engine등)의 빌드 컨텍스트가 Dockerfile이 들어 있는 폴더가 아니라 저장소의 루트를 빌드 컨텍스트로 사용해야 함을 나타냅니다.
컨테이너 이미지 빌드 구성
container-image-builder: (기본값docker) Dockerfile 관련 빌드 시 컨테이너 이미지 빌드에 사용할 도구(docker또는podman)를 지정하십시오.root-as-build-context: (기본값:false)는Dockerfile관련 빌드 도구(예:docker,podman또는code-engine)의 빌드 컨텍스트가 Dockerfile이 포함된 폴더가 아닌 저장소의 루트를 사용해야 함을 나타냅니다.
Golang 구성
Golang 에 대한 스팟 추출 프로세스를 구성하려면 다음 파이프라인 환경 속성을 설정합니다:
go-ignore-main: (기본값: 'false) 메인 소스 인수에 대한 메인 패키지 및 메인 함수 감지에 초점을 맞추지 않도록 코드 스팟 추출을 수행할지 여부를 나타냅니다.go-output' : go 빌드 명령에서 실행 가능한 출력 파일을 지정합니다.
Gradle 구성
설정, 단위 테스트, 빌드 아티팩트 및 승인 테스트에 대한 Gradle 작업을 구성하려면 다음 파이프라인 환경 속성을 사용합니다:
gradle-setup-tasks: (기본값: 'assemble) 쉼표로 구분된 설정 단계용 Gradle 작업 목록입니다.gradle-unit-testing-tasks: (기본값: 'test' ) 단위 테스트 단계에 대한 Gradle 작업의 쉼표로 구분된 목록입니다.gradle-build-artifact-tasks' : (기본값: 'build' ) 빌드 아티팩트 단계에 대한 Gradle 작업의 쉼표로 구분된 목록입니다.gradle-acceptance-testing-tasks' : 쉼표로 구분된 수락 테스트 단계의 Gradle 작업 목록입니다.
NPM 구성
NPM 단위 테스트 및 수락 테스트 스크립트 감지를 구성할 수 있습니다.
hint-npm-unit-testing-script: (기본값: 'test) NPM 단위 테스트 스크립트 감지를 위한 힌트입니다.hint-npm-acceptance-testing-script: (기본값: 'acceptance-test) NPM 허용 테스트 스크립트 감지를 위한 힌트입니다.
Python 구성
Python Poetry 버전을 구성하려면 다음 파이프라인 환경 속성을 사용하세요:
hint-python-poetry-version: (기본값: '1.8.2) Python 시 버전에 대한 힌트입니다.discover-python-unittest-from-ancestor(기본값:false)는 파이썬unittest검색의 시작점으로 조상 디렉터리가 사용됨을 나타냅니다(예: 저장소 루트에서requirements.txt을 포함하는 디렉터리에서 단위 테스트를 검색하기 위해 파이썬 유니테스트 파일에 가장 가까운requirements.txt(있는 경우)이 아닌).
Terraform 구성
Terraform 배포 프로세스를 구성하려면 다음 파이프라인 환경 속성을 사용하세요:
terraform-deployment: (기본값: 'false' ) 상태 저장소로 Terraform 및 Cloud Object Storage 선호하는 배포 수단으로 Schematics 비활성화합니다.
Helm 구성
헬름 릴리스 프로세스를 구성하려면 다음 파이프라인 환경 속성을 사용하십시오:
helm-oci-registry-support: (기본값false) 릴리스 단계에서 헬름 차트를 OCI 레지스트리로 푸시할 수 있도록 활성화합니다.configuration-file-pattern-<config_file_type>: 주어진 유형의 구성 파일을 식별할 수 있는 패턴을 정의하십시오. 예를 들어,configuration-file-pattern-dev-config=chart/dev-values.yaml명령을 실행하면chart/dev-values.yaml에 있는 파일(들)이dev-config`` 유형의 아티팩트로 선택됩니다.
아티팩트 업로드
아티팩트 업로드 프로세스를 구성하려면 다음 파이프라인 환경 속성을 사용하세요:
artifact-upload-to-devsecops-cos: (기본값: 'false' ) 이미지가 저장되지 않은 아티팩트에 대해 DevSecOps CLI 아티팩트 업로드를 사용하여 Cloud Object Storage 버킷에 아티팩트를 업로드할 수 있도록 설정합니다.
환경 설정 파일
각 소스 코드 리포지토리에는 특정 단계에 대한 특정 설정 또는 사용자 지정이 필요합니다. DevSecOps bash 추론된 환경설정 파이프라인 구성 기능은 환경설정 속성을 지정하는 방법을 제공하며, 이 속성은 환경설정 스크립트로 정의될 수 있습니다. 이 스크립트는 프로세스에 대한 해당 작업을 실행하기 전에 소싱됩니다.
이 추론된 devsecops 구성 기능은 파일 이름을 기반으로 한 힌트를 사용하여 환경 설정 파일을 결정합니다. 예를 들어, npm 단위 테스트를 실행하기 전에 호출할 환경 설정 스크립트로 .env.npm-test.sh 라는 이름의 파일이 선택됩니다.
환경 설정 파일의 표준화된 형식은 다음과 같습니다. .env.<process>.sh 또는 .env.<tool>-<process>.sh.
<process> 의 값은 build, test, acceptance-test, deploy, dynamic-scan, release 중 하나일 수 있습니다.
build 의 경우, <tool> 의 값은 code-engine, docker, docker-maven-plugin, go, gradle, helm, maven, npm, pip,
pipenv, poetry, terraform 또는 yarn 중 하나일 수 있습니다.
test 와 acceptance-test 프로세스에서, <tool> 의 값은 go, gradle, helm, maven, npm, pytest, python, terratest 중 하나일 수 있습니다.
deploy 의 경우, <tool> 의 값은 code-engine,helm, kubectl-liberty-app, kubectl, schematics, terraform 중 하나일 수 있습니다.
dynamic-scan 의 경우, <tool> 의 값은 trigger-async-zap 일 수 있습니다.
release 프로세스의 경우 <tool> 값은 maven, poetry 또는 semantic-release 중 하나일 수 있습니다.
다음은 몇 가지 예입니다:
.env.build.sh파일은 코드 스팟의 프로세스 빌드에 대한 환경 설정으로 연결됩니다..env.docker-build.sh,.env.maven-build.sh등과 같은 도커, 메이븐 등과 같은 특정 도구에 대한 환경 설정 파일로 덮어쓸 수 있습니다..env.test.sh파일은 코드 스팟의 프로세스 단위 테스트를 위한 환경 설정으로 연결되어 있습니다..env.go-test.sh,.env.npm-test.sh등과 같은 범위 지정 도구(go, npm 등)의 환경 설정 파일로 재정의할 수 있습니다..env.deploy.sh파일이 배포 지점에서 프로세스에 대한 환경 설정으로 연결되어 있습니다..env.code-engine-deploy.sh,.env.helm-deploy.sh등과 같은 범위 지정 도구(code-engine, helm, kubectl 등)의 환경 설정 파일로 덮어쓸 수 있습니다..env.acceptance-test.sh파일은 승인 테스트 지점에서 프로세스에 대한 환경 설정으로 연결됩니다..env.maven-acceptance-test.sh,.env.python-acceptance-test.sh등과 같은 범위 지정 도구(go, maven, npm 등)의 환경 설정 파일로 덮어쓸 수 있습니다..env.dynamic-scan.sh파일이 동적 스캔 지점에서 프로세스의 환경 설정으로 연결되어 있습니다..env.release.sh파일은 릴리스 스폿의 프로세스에 대한 환경 설정으로 연결됩니다..env.maven-acceptance-test.sh,.env.semantic-release-acceptance-test.sh등과 같은 범위 지정 도구(maven, semantic-release 등)의 환경 설정 파일로 덮어쓸 수 있습니다.
이 스크립트를 사용하는 방법에 대한 예는 IBM Cloud Hello 규정 준수 앱 리포지토리를 참조하세요.
환경 컨텍스트 주입
추론된 DevSecOps 파이프라인 구성 기능은 파이프라인 및 트리거 속성의 환경 변수를 다양한 프로젝트 컨텍스트에 통합합니다. 프로젝트 컨텍스트는 다음과 같습니다:
- 파이프라인 실행 단계
- Helm 배치
- Code Engine 배포
이 기능을 사용하면 파이프라인에서 환경 변수와 같은 컨텍스트를 주입하거나 설정하고 정규화된 속성 이름을 기반으로 속성을 트리거할 수 있습니다.
일부 도구는 다음과 같이 특정 컨텍스트에 삽입되는 정규화된 이름의 프로퍼티를 처리합니다:
- 도커 빌드 인수 및/또는 도커 빌드 시크릿
- Helm 배포를 위한 보완적인 '
values.yaml' 파일 - Code Engine 배포의 경우
configmap' 또는 'secret'
정규화된 속성 이름을 사용하면 파이프라인과 배포에 환경 변수 및 기타 컨텍스트를 주입할 수 있습니다.
파이프라인 실행 단계에서의 환경 변수 주입
추론된 DevSecOps 파이프라인 구성 기능은 단계 실행 중에 파이프라인 및 트리거 속성을 환경 변수로 내보낼 수 있는 ' export-properties 유틸리티를 제공합니다. 이 유틸리티는 모든 사용자 지정 단계에서 호출됩니다:
export-properties "GLOBAL" && export-properties "${STAGE^^}"
글로벌 환경 변수
' export-properties "GLOBAL" ' 명령은 모든 파이프라인 단계 실행 컨텍스트에서 ' ENV_GLOBAL_<XXX> '를 환경 변수로 사용하여 정규화된 이름을 가진 파이프라인 및 트리거 속성을 ' XXX '과 같이 내보냅니다.
글로벌 환경 변수의 예
| 특성 이름 | 부동산 평가사 | 결과 환경 변수 |
|---|---|---|
ENV_GLOBAL_my_var |
my_value |
my_var=my_value |
스테이지별 환경 변수
' export-properties "${STAGE^^}" ' 명령은 현재 실행 단계와 관련된 파이프라인 또는 트리거 속성을 정규화된 이름 ' ENV_<stage in upper case>_<XXX> '로 지정된 실행 단계의 환경 변수로 내보냅니다.
스테이지별 환경 변수 예시
| 특성 이름 | 부동산 평가사 | 결과 환경 변수 |
|---|---|---|
ENV_SETUP_CGO_ENABLED |
true |
CGO_ENABLED=true |
CI 파이프라인에서 ' code-setup - run-stage ' 단계에는 ' CGO_ENABLED ' 환경 변수가 적절한 값으로 설정되어 있습니다.
스테이지 목록과 스테이지에 대한 설명은 스테이지 설명을 참조하세요.
이 기능의 일반적인 사용 사례는 단위 테스트를 실행하기 전에 환경 변수를 주입하여 구성을 제공하는 것입니다. 이 경우 프로퍼티의 정규화된 이름은 ' ENV_TEST_<a_var> '이 되고, ' <a_var> '는 테스트` 단계 실행에 사용할 수 있도록 내보낸 환경 변수의 이름이 됩니다.
예
| 특성 이름 | 부동산 평가사 | 결과 환경 변수 |
|---|---|---|
ENV_TEST_MY_VAR |
my_value |
MY_VAR=my_value |
이 기능을 사용하면 파이프라인 구성을 간소화하고 배포 전반의 일관성을 개선할 수 있습니다.
도구 실행 및 구성
추론된 DevSecOps 파이프라인 구성 기능의 일부 도구는 파이프라인 및 트리거 속성을 사용하여 상호 보완적인 구성을 추론합니다.
Docker
- 빌드 인수: 도커 빌드 명령은 파이프라인 및 '
DOCKER_BUILD_ARG_과 같이 정규화된 이름을 가진 트리거 속성을 기반으로 --build-arg 매개 변수를 사용하여 완료됩니다.- 예시: 예: 이름이 '
DOCKER_BUILD_ARG_my_arg인 속성을 추가하면 '--build-arg="my_arg="' 매개 변수가 docker 빌드 명령에 삽입됩니다.
- 예시: 예: 이름이 '
- 빌드 시크릿: 도커 빌드 명령은 파이프라인 및 트리거 속성을 기반으로 하는 --secret 매개 변수와 '
DOCKER_BUILD_SECRET_'과 같이 정규화된 이름을 가진 매개 변수를 사용하여 완료됩니다.- 예를 들어, DOCKER_BUILD_SECRET_my_secret이라는 이름의 속성을 추가하면 --secret id=my_secret,env= 매개 변수가 docker 빌드 명령에 주입됩니다.
자세한 내용은 도커 빌드 인자 및 도커 빌드 시크릿을 참조하세요
Helm
- 배포 처리: 정규화된 파이프라인 및 트리거 속성을 기반으로 Helm 배포 프로세스에 추가 값을 주입할 수 있다.
- 속성의 이름이 '
HELM_VALUE_,'과 같은 경우 Helm 처리 도구에서 관리하는 보완 값 파일은 파이프라인 또는 트리거 속성 값과 함께 'a_value_property' 항목을 추가한다. - 보완값 파일은 헬름 명령의 마지막 '
-f | --values매개변수의 인수로 사용됩니다.
- 속성의 이름이 '
자세한 내용은 보완적 가치 콘텐츠를 참조하세요.
Terraform
- 배포 프로세스 Terraform 도구는 규정 준수 공통 테라폼에서 제공하는 테라폼 도우미 기능을 사용합니다.
- 컨텍스트 주입을 위한 구성 속성에 대한 자세한 내용은 Terraform 입력 변수 구성을 참조하세요.
Schematics
- 배포 프로세스: Schematics 도구는 컴플라이언스 공통 스키마에서 제공하는 Schematics 도우미 기능을 사용합니다.
- 컨텍스트 주입을 위한 구성 속성에 대한 자세한 내용은 Schematics 작업 공간 선언 변수 구성하기를 참조하세요.
Code Engine
- 배포 프로세스: 애플리케이션에 대한 추가 구성은 애플리케이션과 관련된 보완적인 컨피그맵 또는 시크릿을 정의하여 만들 수 있습니다.
- '
CE_ENV_<XXXX>'과 같이 정규화된 이름을 가진 파이프라인 및 트리거 속성의 경우, 해당 파이프라인 또는 트리거 속성의 값을 기반으로 설정된 키 '<XXXX>'와 해당 값을 사용하여 보완 구성 맵 또는 비밀( Code Engine 애플리케이션 또는 작업과 연결됨)의 항목이 생성됩니다.
- '
자세한 내용은 애플리케이션 또는 작업을 구성하는 코드 엔진 구성 맵 및 애플리케이션 또는 작업을 구성하는 코드 엔진 시크릿을 참조하세요
DevSecOps 공통 스크립트 라이브러리
추론된 DevSecOps 파이프라인 구성은 공통 라이브러리의 스크립트에서 특정 단계의 스크립트/함수를 사용하며, 사용자 지정으로 시작하려는 경우 도움이 될 수 있는 재사용 가능한 스크립트 집합을 제공합니다.
스크립트, 도구, 사용법, 매개변수 등 공통 스크립트 라이브러리에 대한 자세한 내용은 공통 스크립트 라이브러리를 참조하세요.
FAQ
지점 보호
기본적으로 브랜치 보호 사용
DevSecOps PR 및 CI 파이프라인은 기본적으로 소스 코드 리포지토리에서 브랜치 보호를 활성화합니다. 이 확인은 코드 설정 단계에서 이루어집니다.
지점 보호 비활성화
브랜치 보호를 비활성화하려면 ' setup-branch-protection 속성을 ' false'로 설정합니다.
지점 보호 상태 확인 사용자 지정
브랜치 보호 상태 확인을 위한 접두사를 사용자 지정하려면 ' branch-protection-status-check-prefix ' 속성을 설정합니다. 기본 접두사는 ' tekton 입니다.
사전 커밋 후크의 구성과 실행
DevSecOps 기본적으로, PR과 CI 파이프라인은 소스 코드 저장소에 pre-commit 구성 파일이 존재하는 경우, 설정 단계에서 pre-commit 후크를 실행합니다(기본값: .pre-commit-config.yaml ). 사전 커밋 구성 파일의 이름은 파이프라인/트리거 속성 pre-commit-config-file 을 구성 파일의 이름으로 설정하여 지정할 수 있습니다.
일부 프리 커밋 후크는 건너뛰어질 수 있습니다(예를 들어, detect-secrets 와 같은 특정 후크가 PR 또는 CI 파이프라인의 특정 단계에서 실행되기 때문입니다). 건너뛰고자 하는 후크를 지정하려면, 파이프라인/트리거 속성 pre-commit-skip-hooks 을 건너뛰고자 하는 후크 id의 쉼표로 구분된 목록으로 설정하십시오.
자체 서명 인증서가 있는 Sonarqube 서버
sonarqube-config 가 custom 로 설정되어 있고 기존 sonarqube 서버를 사용하며 해당 서버에 자체 서명 인증서가 있는 경우, sonar 스캐너가 sonarqube 서버에 성공적으로 연결하려면 자체 서명
인증서를 신뢰할 수 있는 CA 인증서에 추가해야 합니다.
파이프라인/트리거 속성 sonarqube-root-certificate 의 값으로 PEM 형식으로 인증서를 제공하면, Inferred DevSecOps 파이프라인 구성의 정적 스캔 구현은 maven의 경우 SonarScanner, gradle sonar의 경우 SonarScanner 또는 Docker 으로 호출된 SonarScanner 의 사용을 위해 적절하게 추가합니다.
시 및 비공개 리포지토리
비공개 리포지토리에 대한 시 구성하기
Poetry(pyproject.toml '은 코드 스팟으로 식별됨)를 사용하고 다음과 같이 종속성을 가져오기 위해 대체 소스 또는 리포지토리가 정의되어 있는 경우:
[[tool.poetry.source]]
name = "local"
url = "<artifactory-url>"
secondary = true
또는 Poetry가 관련된 경우(예: build-system 섹션이 포함된 pyproject.toml, build-backend 이 식별된 릴리스 지점인 경우 poetry.core.masonry.api ) 비공개 레지스트리에 인증하기 위해 자격 증명을 제공해야 할 수 있습니다.
IBM Cloud 사설 리포지토리로 인증하기
이 ' local 소스 리포지토리에 대한 자격 증명을 제공해야 합니다. 자격 증명 구성에 대한 시 문서에 따르면 http 사용자 및 비밀번호를 제공하는 환경 변수는 ' POETRY_HTTP_BASIC_LOCAL_USERNAME '과
' POETRY_HTTP_BASIC_LOCAL_PASSWORD'여야 한다고 명시되어 있습니다.
환경 변수 주입 기능을 사용하여 다음 파이프라인 환경 속성을 추가합니다:
- 적절한 값으로
ENV_GLOBAL_POETRY_HTTP_BASIC_LOCAL_USERNAME'(텍스트)을 입력합니다 - 적절한 보안 값을 가진
ENV_GLOBAL_POETRY_HTTP_BASIC_LOCAL_PASSWORD'(보안됨)
비공개 리포지토리에 게시하려면 인증하기
Poetry가 포함된 경우(예: build-system 섹션이 포함된 pyproject.toml, build-backend 이 식별된 릴리스 지점인 경우 poetry.core.masonry.api ), 토큰 또는 사용자 이름에 대한 구성은 ( local 이라는 리포지토리의 경우)와
같은 파이프라인 환경 속성을 사용하여 정의할 수 있습니다:
- 적절한 값으로
ENV_GLOBAL_POETRY_HTTP_BASIC_LOCAL_USERNAME'(텍스트)을 입력합니다 - 적절한 보안 값을 가진
ENV_GLOBAL_POETRY_HTTP_BASIC_LOCAL_PASSWORD'(보안됨)
or
ENV_GLOBAL_POETRY_PYPI_TOKEN_LOCAL(보안) 토큰에 해당하는 적절한 보안 값으로 (보안)
Maven, pom.xml, settings.xml 및 환경 해상도
IBM Cloud 사용자 지정 설정 파일에 대한 Maven 구성
Maven 프로젝트에서 ' ci-settings.xml 과 같은 사용자 지정 파일 이름으로 특정 설정 파일을 정의하는 경우 PR, CI 파이프라인 또는 트리거 수준 속성에서 값이 ' ci_settings.xml '로 설정된 파이프라인 환경 속성 maven-user-settings-file-path를 정의합니다.
또한 다음과 같이 해결해야 할 ' env.<VARIABLE> '이 있는 경우:
<server>
<username>${env.MAVEN_USERNAME}</username>
<password>${env.MAVEN_PASSWORD}</password>
<id>central</id>
</server>
환경 변수 주입 기능을 사용하여 PR 및 CI 파이프라인에 2개의 파이프라인 속성을 추가하여 이러한 변수를 제공하세요:
- maven 사용자 이름에 사용할 값으로
ENV_GLOBAL_MAVEN_USERNAME'(텍스트)을 추가합니다 ENV_GLOBAL_MAVEN_PASSWORD'(보안)을 maven 비밀번호에 사용할 값으로 설정합니다
Go 빌드를 위한 강제 정적 링크
Go 빌드에 정적 링크 활성화
기본적으로 ' go build '은 동적으로 연결된 바이너리를 생성합니다. Docker 컨테이너에서 사용하려면 빌드 중에 ' CGO_ENABLED=0 '을 설정하여 정적 링크를 활성화하세요.
Go 빌드를 위한 환경 변수 구성
정적 연결을 사용하려면 환경 변수 주입 기능을 사용하여 CI 파이프라인에 다음 파이프라인 환경 속성을 추가하세요:
ENV_SETUP_CGO_ENABLED값을 '0'로 설정합니다
지원 받기
IBM Cloud IBM 의 AI 어시스턴트( )는 에서 일하는 것과 이용 가능한 카탈로그를 이용해 솔루션을 구축하는 것에 대해 배울 수 있도록 설계되었습니다. watsonx IBM Cloud AI 어시스턴트로부터 도움 받기를 참조하세요.
그래도 문제점을 해결할 수 없는 경우 지원 케이스를 열 수 있습니다. 자세한 정보는 지원 케이스 작성을 참조하십시오. 피드백을 제공하고자 하는 경우, 피드백 제출하기를 참조하십시오.