(CloudBees Plugins 가이드의 Template 플러그인 정보에서 각색)
여러 Jenkins 플러그인은 사용자가 Jenkins의 동작을 사용자 지정하기 위해 사용자 정의 스크립트, 가장 일반적으로는 Groovy 언어로 작성된 스크립트를 정의하도록 요구합니다. 이러한 스크립트를 작성하는 모든 사람이 Jenkins 관리자라면 — 구체적으로 Script Console 링크에서 사용하는 Overall/RunScripts 권한이 있다면 — 원하는 스크립트를 무엇이든 작성할 수 있습니다. 이러한 스크립트는 플러그인에 제공되는 것과 동일한 API를 사용하여 Jenkins 내부 객체를 직접 참조할 수 있습니다. 이러한 사용자는 Jenkins에 무엇이든 할 수 있으므로(보안 설정 변경 또는 서버에서 셸 명령 실행까지도) 완전히 신뢰할 수 있는 사람이어야 합니다.
그러나 일부 스크립트 작성자가 Job/Configure와 같은 더 제한적인 권한만 가진 "일반 사용자"라면 임의의 스크립트를 실행하도록 허용하는 것은 부적절합니다. 이러한 역할 구분을 지원하기 위해 Script Security 라이브러리 플러그인은 다양한 기능 플러그인에 통합될 수 있습니다. 이 플러그인은 스크립트 승인(script approval)과 Groovy 샌드박싱(Groovy sandboxing)이라는 두 가지 관련 시스템을 지원합니다.
첫 번째이자 더 간단한 보안 시스템은 모든 종류의 스크립트 실행을 허용하되 관리자의 승인을 받도록 하는 것입니다. 악의적인 동작을 수행하지 않는다고 판단되는 승인된 스크립트 목록이 전역적으로 유지됩니다.
관리자가 어떤 종류의 구성(예: 작업)을 저장하면 관리자가 편집한 스크립트는 자동으로 승인되며 추가 조치 없이 실행할 준비가 됩니다. 하위 권한 사용자가 제출한 스크립트의 경우 승인이 필요함을 알리는 적절한 경고가 표시됩니다. 관리자는 스크립트 승인 구성 페이지를 사용하거나 스크립트를 편집하고 저장하여 해당 스크립트를 승인할 수 있습니다. 이전 버전의 Script Security Plugin에서는 관리자가 권한이 없는 사용자가 제출한 스크립트를 변경 없이 저장하기만 해도 자동으로 승인할 수 있었지만, 이 기능은 사회 공학 기반 공격을 방지하기 위해 비활성화되었습니다. ("저장"은 일반적으로 웹 UI를 의미하지만 REST 또는 CLI를 통해 새 XML 구성을 업로드하는 것을 의미할 수도 있습니다.)
관리자가 아닌 사용자가 템플릿 구성을 저장하면 포함된 스크립트 중 승인된 텍스트에서 편집된 것이 있는지 확인합니다. (더 정확히는 요청된 콘텐츠가 이전에 승인된 적이 있는지 여부를 확인합니다.) 승인된 적이 없다면 이 스크립트에 대한 승인 요청이 큐에 추가됩니다. (또한 스크립트의 현재 텍스트가 현재 승인되지 않은 경우 구성 화면 UI에 경고가 표시됩니다.)
관리자는 이제 _Manage Jenkins » In-process Script Approval_로 이동하여 승인 대기 중인 스크립트 목록을 볼 수 있습니다. 위험해 보이는 것이 요청되지 않았다면 Approve를 클릭하기만 하면 이후로 스크립트가 실행될 수 있습니다.
승인되지 않은 스크립트를 실행하려고 하면 단순히 실패하며, 일반적으로 승인 대기 중이라는 메시지가 표시됩니다. 스크립트가 승인된 후에 다시 시도할 수 있습니다. 이 동작의 세부 사항은 이 라이브러리를 통합하는 기능 플러그인에 따라 다를 수 있습니다.
아무리 사소해 보이는 변경이라도 스크립트의 모든 변경 사항을 관리자가 승인할 때까지 기다리는 것은 여러 시간대에 걸친 팀이나 촉박한 마감 기한 동안에는 받아들일 수 없을 수 있습니다. 대안으로 Script Security 시스템은 Groovy 스크립트가 본질적으로 안전하다고 간주되는 작업으로만 제한한다면 승인 없이 실행되도록 허용합니다. 이 제한된 실행 환경을 샌드박스라고 합니다. (현재 다른 언어에 대한 샌드박스 구현은 없으므로 관리자가 아닌 사용자가 구성하는 경우 이러한 모든 스크립트는 승인되어야 합니다.)
이 모드로 전환하려면 Groovy 스크립트 입력 필드 아래의 Use Groovy Sandbox 확인란을 선택하기만 하면 됩니다. 샌드박스 처리된 스크립트는 누구나 즉시 실행할 수 있습니다. (관리자도 마찬가지이지만, 작성자가 누구든 관계없이 스크립트는 동일한 제한을 받습니다.) 스크립트가 실행될 때 모든 메서드 호출, 객체 생성 및 필드 액세스는 승인된 작업의 화이트리스트와 대조하여 확인됩니다. 승인되지 않은 작업이 시도되면 스크립트가 중단되고 해당 Jenkins 기능은 아직 사용할 수 없습니다.
Script Security 플러그인은 작은 기본 화이트리스트를 제공하며, 통합 플러그인은 해당 목록에 작업을 추가할 수 있습니다 (일반적으로 해당 플러그인에 특화된 메서드).
하지만 기본 화이트리스트에만 제한되지는 않습니다. 아직 화이트리스트에 없는 작업을 실행하기 전에 스크립트가 실패할 때마다 해당 작업이 자동으로 다른 승인 큐에 추가됩니다. 관리자는 전체 스크립트 승인에 대해 위에서 설명한 것과 동일한 페이지로 이동하여 대기 중인 작업 승인 목록을 볼 수 있습니다. 작업 시그니처 옆에 Approve를 클릭하면 즉시 화이트리스트에 추가되어 샌드박스 스크립트에서 사용할 수 있습니다.
대부분의 시그니처는 method class.Name methodName arg1Type arg2Type… 형식으로,
특정 "수신자" 클래스(this), 메서드 이름 및 인수(또는 매개변수) 유형 목록이 있는 Java 메서드 호출을 나타냅니다.
(시도된 메서드 호출의 가장 일반적인 시그니처가 승인 대상으로 제공되며, 실제로 호출 대상이었던 객체가 해당 메서드를
재정의하는 더 구체적인 유형이었더라도 마찬가지입니다.) 또한 정적(클래스) 메서드의 경우 staticMethod, 생성자의 경우
new, 필드 액세스(가져오기 또는 설정)의 경우 field를 볼 수 있습니다.
보안에 민감한 환경의 관리자는 어떤 작업을 화이트리스트에 추가할지 신중히 고려해야 합니다.
지속 객체(Jenkins 작업 등)의 상태를 변경하는 작업은 일반적으로 거부해야 합니다. 대부분의 getSomething 메서드는
무해합니다.
그러나 일부 "getter" 메서드도 특정 권한을 확인하도록 설계되었다는 점에 유의하십시오
(ACL: 액세스 제어 목록 사용). 반면 스크립트는 모든 권한이 부여된 시스템 의사 사용자로 실행되는 경우가 많습니다.
예를 들어 method hudson.model.AbstractItem getParent(작업이 포함된 폴더 또는 Jenkins 루트를 가져오는 메서드)는
그 자체로는 무해하지만, 후속 호출인 method hudson.model.ItemGroup getItems(폴더 내에서 이름별로 작업을 나열하는 메서드)는
Job/Read를 확인합니다. 이 두 번째 호출을 무조건 화이트리스트에 추가하는 것은 위험합니다.
폴더에서 Job/Create 권한을 부여받은 사용자가 프로젝트 기반 권한 부여 전략에 따라 숨겨져 있어야 하는 작업을 포함하여
해당 폴더의 모든 작업에서 최소한 일부 정보를 읽을 수 있게 되기 때문입니다. 폴더에 다음과 같은 Groovy 스크립트가 포함된
작업을 생성하는 것만으로 충분합니다(세부 사항은 통합 플러그인에 따라 다름):
println("I sniffed ${thisjob.getParent().getItems()}!");
실행되면 스크립트 출력에는 기밀 프로젝트로 추정되는 항목의 이름이 최소한 표시됩니다.
관리자는 대신 getItems에 대한 권한 확인을 가정하고 Approve를 클릭할 수 있습니다. 이렇게 하면 실제 사용자로 실행될 때
(통합 플러그인이 그렇게 하는 경우) 호출이 허용되고, 시스템 사용자로 실행될 때(더 일반적인 경우)에는 금지됩니다.
이 경우 getItems는 실제로 현재 사용자가 액세스할 수 있는 작업만 반환하도록 구현되어 있으므로 전자의 경우(특정 사용자로)
실행하면 설명에는 어차피 볼 수 있었던 작업만 표시됩니다. 이 고급 버튼은 메서드 호출(및 생성자)에 대해서만 표시되며,
Jenkins가 권한 확인을 수행하고 있음을 아는 경우에만 사용해야 합니다.
일반적인 Groovy 통합의 경우, 사용자에게 스크립트 승인 또는 샌드박스 사용 옵션을 제공하려면
describable의 String 값 스크립트 필드를 SecureGroovyScript 필드로 변경하십시오.
생성자에서 값을 저장하기 전에 configuringWithKeyItem(최상위 항목당 이러한 스크립트가 하나만 있을 수 있는 경우) 또는
configuringWithNonKeyItem(여러 개가 있을 수 있는 경우)을 호출하십시오. 구성 양식은
<f:property field="…"/>를 사용하여 스크립트 및 샌드박스 구성을 가져와야 합니다.
스크립트를 실행하려면 evaluate를 호출하기만 하면 됩니다.
(이전 데이터와의 호환성을 위해 다른 필드 이름을 선택하고 원래 필드는 더 이상 사용하지 않도록 지정하십시오.
그런 다음 샌드박스가 꺼진 SecureGroovyScript로 새 필드를 설정하고, configuring(ApprovalContext.create())를 호출하여
시스템에 승인되지 않은 스크립트가 로드되었음을 알린 다음, 이전 필드를 해제하는 readResolve 메서드를 정의할 수 있습니다.)
SecureGroovyScript가 제공하는 것보다 더 많은 제어가 필요한 경우 사용합니다.
구성에 boolean 샌드박스 필드를 도입하십시오.
설정되지 않은 경우 @DataBoundConstructor에서 ScriptApproval.configuring을 호출해야 합니다.
ApprovalContext.withCurrentUser를 사용하고, 해당되는 경우(작업당 스크립트가 하나만 있는 경우) withItemAsKey도 사용하십시오.
그렇지 않은 경우 해당되면 최소한 withItem을, 그리고/또는 컨텍스트에서 이 사용법을 고유하게 식별할 수 있는 경우
withKey를 사용하십시오(StaplerRequest.findAncestorObject가 여기서 유용합니다). 이렇게 하면 시스템이
특정 개인이 (새로) 스크립트를 구성했음을 알 수 있습니다. 또한 디스크에서 스크립트가 포함된 구성 가능 항목이 로드될 때
(따라서 구성자가 알려지지 않은 경우) 시스템에 알리기 위해 configuring을 호출하는 readResolve도 필요합니다.
스크립트가 실행될 때 ScriptApproval.using을 호출하고 필요한 경우 UnapprovedUsageException을 catch하십시오.
descriptor는 스크립트 필드에 대한 양식 유효성 검사를 사용하고 ScriptApproval.checking을 호출해야 합니다
(일반적으로 descriptor는 이미 이 필드에 대해 최소한 구문 검사를 수행하고 있어야 합니다).
샌드박스 필드가 설정된 경우 GroovySandbox.createSecureCompilerConfiguration으로 Groovy 셸을 설정한 다음
GroovySandbox.run을 호출하기만 하면 됩니다. RejectedAccessException을 catch하고
ScriptApproval.accessRejected를 호출할 준비를 하십시오.
특정 메서드 호출을 사전 승인하려면 플러그인에 있는 경우 간단히 @Whitelisted로 주석을 달면 됩니다.
그렇지 않으면 StaticWhitelist.from에 위임하고 화이트리스트에 추가된 메서드를 나열하는 텍스트 파일을 로드하는
ProxyWhitelist를 (@Extension으로) 등록할 수 있습니다.
스크립트를 평가하기 위해 GroovyShell을 구성하거나 SecureGroovyScript.evaluate를 호출할 때
스크립트의 유효 클래스패스를 나타내는 ClassLoader를 전달해야 합니다. Jenkins 코어의 로더, 플러그인의 로더 또는
Jenkins.getInstance().getPluginManager().uberClassLoader를 사용할 수 있습니다.
무엇을 선택하든 권한이 없는 사용자가 URLClassLoader를 만들어 임의의 클래스패스 항목을 추가하도록 허용하지 마십시오!
이렇게 하면 샌드박스를 사용할 때 모든 보안을 쉽게 우회할 수 있습니다. (사용자는 이 작업이나 다른 작업이
@Whitelisted로 표시된 정적 메서드를 포함하고 원하는 대로 수행하는 클래스가 있는 JAR을 보관하도록 한 다음
스크립트에서 해당 메서드를 호출하기만 하면 됩니다.) 전체 스크립트 승인을 사용할 때는 아직 공격이 입증되지 않았지만
(일반적인 부모 우선 위임을 사용하는 URLClassLoader는 손상된 버전으로 무해해 보이는 API를 쉽게 위장하는 것을 허용하지
않습니다) META-INF/services/org.codehaus.groovy.transform.ASTTransformation 또는 이와 유사한 것을 영리하게 사용하면
그 외에는 안전한 스크립트가 예상치 못한 인증되지 않은 방식으로 동작할 수 있습니다.
JENKINS-22834는 안전한 표준 대안을 제안합니다.
Script Security Plugin을 사용하는 플러그인 테스트를 작성할 때 테스트에서 일부 오류가 발생할 수 있습니다.
테스트가 직간접적으로 ScriptApproval.get() 메서드를 호출하는 경우 단위 테스트는 JenkinsRule을 사용하여
Jenkins.getInstance()가 null을 반환하지 않도록 해야 합니다. 샌드박스를 사용하지 않는 경우 지금까지 작동하던 테스트가
실패하기 시작할 가능성이 높습니다. 승인 큐에 등록되기 때문입니다. 승인 여부와 관계없이 스크립트를 실행해야 하는 경우
ScriptApproval.get().preapprove(script, GroovyLanguage.get())를 사용하면 구성된 모든 스크립트가 승인되도록 할 수
있습니다. 또는 테스트가 샌드박스를 사용하여 스크립트를 실행하도록 할 수 있습니다. 이 경우 테스트에서 사용하는 메서드를
화이트리스트에 추가해야 할 수 있습니다. 실제 사용자를 위해 일반적으로 추가하거나 @TestExtension을 사용하여
테스트 전용 화이트리스트를 가질 수 있습니다.
변경 로그 참조
