我有一个带有Jenkinsfile的GitHub存储库设置。GitHub Organization Folder插件将从提供的Jenkinsfile执行管道。
管道的最后一步是部署步骤。部署步骤使用CloudBees Amazon Web Services凭据插件检查分支是否具有AWS凭据。如果检测到凭据,它将部署,否则将不会部署。
每当他们想要更改某些内容时,所有成员都具有对GitHub存储库的只读访问权限,他们必须创建拉取请求。(只有管理员可以合并)如果有新的拉取请求,Jenkins服务器将运行管道直到部署步骤,检查拉取请求是否可以集成到master分支中。管道的最后一步是部署步骤,不应对请求请求执行此步骤。
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运行管道?还是如何使用master分支中的Jenkinsfile发出拉取请求?