개발자가 저장소에 코드를 푸시 한 다음 CI 서버에서 빌드를 트리거하는 설정이 있습니다. 배포는 현재 CI 서버에서도 수행됩니다. 프로덕션 환경에 배포하려면 젠킨스가 prod-server에 루트로 로그인해야합니다.빌드 서버에서 자격 증명을 확보하는 방법은 무엇입니까?
즉, 자격 증명 (예 : 사용자 이름/비밀번호 또는 비밀 키)을 CI 시스템에 입력해야한다는 의미입니다. 이로 인해 저장소에 액세스 할 수있는 모든 개발자는 코드를 빌드 프로세스에 삽입하여 이러한 보안 자격 증명을 읽을 수 있습니다.
Repo에 대한 액세스가 CI 서버의 자격 증명에 액세스하지 못하게하려면 어떻게해야합니까?
젠킨스의 "Credentials"객체 ("Credentials"플러그인)를 사용할 수 있습니다. Jenkins 사이드 메뉴에서 "Credentials"로 이동하고 새 Credentials 항목을 만듭니다. 이러한 항목은 Jenkins 내부에 저장되며 SCM 저장소에는 저장되지 않습니다.
그런 다음 Jenkins 파이프 라인 또는 자유형 작업의 자격 증명을 사용할 수 있습니다. 개발자가 자격 증명에 액세스 할 수 없도록 젠킨스 권한을 설정합니다. Jenkins는 별표 (***)로 대체하여 콘솔 자격 증명에 해당 자격 증명이 누출되지 않도록 보호합니다.
젠킨스 파일을 사용하는 경우 실제로 개발자에게 모든 권한을 부여하고 있습니다. 이는 보안상의 나쁜 관행입니다. Developer와 DevOps 역할을 분리하기 위해 프로덕션에만 아티팩트를 배포하는 Jenkins 작업을 별도로 만들었습니다. 배포 파이프 라인을 jenkinsfile에 저장하거나 다른 권한을 가진 새로운 "DevOps"저장소에 저장하지 마십시오. 빌드 작업이 성공하면 배포 작업을 트리거하도록 구성합니다. 범위/권한을 사용하여 자격 증명 및 배포 작업에 대한 액세스 보호
Jenkinsfile이 SCM이므로이 솔루션은 개발자가 자격 증명을 얻는 것을 방해하지 않습니다. 개발자는 예를 들어, 자격 증명을 파일로 덤프하고 아티팩트로 다운로드하십시오 (별표로 덮어 쓰지 않습니다) – gorootde
jenkinsfile을 사용하고 있다면 개발자에게 실제로 모든 권한을 부여하고 있습니다. 이는 보안상의 나쁜 관행입니다. Developer와 DevOps 역할을 분리하기 위해 프로덕션에만 아티팩트를 배포하는 Jenkins 작업을 별도로 만들었습니다. 배포 파이프 라인을 jenkinsfile에 저장하거나 다른 권한을 가진 새로운 "DevOps"저장소에 저장하지 마십시오. 빌드 작업이 성공하면 배포 작업을 트리거하도록 구성합니다. 범위/권한을 사용하여 자격 증명 및 배포 작업에 대한 액세스를 보호하십시오. –
'jenkins는 prod-servers에 루트로 로그인해야합니다 .' 왜 prod-server를 Jenkins 노예로 설정하지 않습니까? – Tuan
제가 볼 수있는 한, 이것은 하나의 것을 변화시키지 않습니다. 코드 beeing 빌드 (및 Buildplan)는 안전하지 않을 수 있으며 비밀 정보를 수집 할 수 있습니다. – gorootde