我使用 Jenkinsfile 进行 Bitbucket REST API 调用。

Jenkinsfile 的原始版本使用超级用户的用户名：密码作为 curl 的 -u 参数。例如

pipeline {
  agent any
  stages {
    stage( "1" ) {
      steps {
        script {
          def CRED = "super_user:super_password"
          def url = "https://bitbucket.company.com/rest/build-status/1.0/commits"
          def commit = 0000000000000000000000000000000000000001
          def dict = [:]
          dict.state = "INPROGRESS"
          dict.key = "foo_002"
          dict.url = "http://server:8080/blue/organizations/jenkins/job/detail/job/002/pipeline"
          def cmd = "curl " +
                    "-f " +
                    "-L " +
                    "-u ${CRED} " +
                    "-H \\\"Content-Type: application/json\\\" " +
                    "-X POST ${url}/${commit} " +
                    "-d \\\''${JsonOutput.toJson(dict)}'\\\'"
          sh(script: cmd)
        }
      }
    }
  }
}

我不认为 def CRED = "super_user:super_password" 是安全的——即用户名/密码以明文形式存在。所以我四处寻找替代品。

建议我使用个人访问令牌 (PAT) 而不是用户名/密码。

我recently learned认为 PAT 实际上是现有用户的“另一个密码”。 IE。如果注意到的 super_user 在 Bitbucket 网络用户界面中创建了一个 PAT——以“00000000000000000000000000000000000000000000”为例——那么对上述 Jenkinsfile 的唯一更改是：

def CRED = "super_user:00000000000000000000000000000000000000000000"

为什么认为这更安全？明文 super_user:00000000000000000000000000000000000000000000 的存在是否与明文 super_user:super_password 的存在一样具有安全漏洞？

This Bitbucket REST API documentation 提供了 curl 命令的示例，用于调用更新提交构建状态的 REST API，这是上述 Jenkinsfile 实现的。

由于调用 REST API 最终归结为 curl 命令——即在 shell 提示中调用的东西，无论是人工还是 Jenkinsfile 脚本——什么是保护用户名：密码的流行约定/PAT 使其不是 Jenkinsfile 中的明文（或通过调用 readFile() 等读取的文件）?