Question

我有一个使用Jenkins文件的GitHub repo设置。 GitHub组织文件夹插件将从提供的Jenkinsfile执行管道。

管道的最后一步是部署步骤。部署步骤使用CloudBees Amazon Web Services凭据插件检查分支是否具有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为更改的Jenkins文件运行管道？或者如何让pull请求使用master分支中的Jenkins文件呢？

Answer 1

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

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

Answer 2

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

Jenkins在拉取请求

2 个答案: