8

我有一个带有 Jenkinsfile 的 GitHub 存储库设置。GitHub 组织文件夹插件将从提供的 Jenkinsfile 执行管道。

管道的最后一步是部署步骤。部署步骤使用 CloudBees Amazon Web Services Credentials Plugin 检查分支机构是否具有 AWS 凭证。如果它检测到凭据，它将部署，否则不会。

所有成员都对 GitHub 存储库具有只读访问权限，每当他们想要更改某些内容时，他们必须创建拉取请求。（只有管理员可以合并）如果有新的拉取请求，Jenkins 服务器将运行管道直到部署步骤，检查拉取请求是否可以集成到主分支。管道的最后一步是部署步骤，这不应该针对拉取请求执行。

stage('Deploy') {

    // Deploy with the right credentials
    try {
        withCredentials([[
            $class: 'AmazonWebServicesCredentialsBinding', 
            accessKeyVariable: 'AWS_ACCESS_KEY_ID', 
            credentialsId: env.BRANCH_NAME + '_AWS_Credentials', 
            secretKeyVariable: 'AWS_SECRET_ACCESS_KEY'
        ]]) {
            echo("Deploying to " + env.BRANCH_NAME + "...")
            ...
        }
    } catch(all) {
        echo("Not deploying for branch: " + env.BRANCH_NAME)
    }
}

问题是团队成员可以使用更改后的 Jenkinsfile 创建拉取请求。

因此，假设其中一名团队成员被黑了。他们现在可以通过使用更改后的 Jenkinsfile 创建拉取请求来感染生产环境，该请求执行以下操作：

credentialsId: 'master_AWS_Credentials',

如何防止 Jenkins 为更改的 Jenkinsfile 运行管道？或者我如何使用主分支中的 Jenkinsfile 来发出拉取请求？

4

2 回答 2

0

据我所知，它没有记录，但只有来自存储库分支的拉取请求才能执行更改的 JenkinsFile。如果有人提出分叉和拉取请求，Jenkins 执行的 Jenkins 文件将是拉取请求的目标分支之一，而不是拉取请求的分支之一。

如果需要管理员级别来合并任何内容（不仅是主分支），那么您是安全的。

于 2017-01-16T20:50:47.543 回答
-3

您可能忘记为 jenkins 文件添加处理程序，查看存储库以获取预防设置。希望这将为您解决。

于 2017-01-12T19:25:18.540 回答