如何能秘密API密钥，而使用公共构建服务器使用 [英] How can secret API keys be used while using public build servers

问题描述

马克·墨菲使得上的他的博客什么样的​​信息应该被拒之门外的公共库。密钥材料，例如OAuth的密钥或API密钥各种服务，是一个很好的例子。

Mark Murphy makes a good case on his blog what kind of information should be kept out of public repositories. Key material, e.g. OAuth keys or API keys to various services, are a prime example for this.

在问题中的应用将是移动Android应用程序，所以有人反编译它获得的密钥是不是在这个问题的范围。

The application in question would be a mobile android app, so someone decompiling it to get at the secret keys is not in scope of this question.

将如何在公共CI实例的构建工作，例如CloudBees的，进行配置，这个秘密是不是在构建日志或编译目录泄露？我的主要目的是展示建筑和不传播我的私人钥匙都在互联网上建立基于OAuth的认证的应用程序的过程。因此，需要有一个公共code库和一个公共可见构建服务器。

How would a build job on a public CI instance, for example cloudbees, be configured so the secret is not leaked in the build log or the compile directory? My main intent is demonstrating the architecture and build process of an app with OAuth-based authentication without disseminating my private keys all over the internet. Therefore, the need for a public code repository and a publicly visible build server.

目前，我使用maven过滤和占位符在我的Java code创建静态常量类，但这些类总是在目标目录中可见。目标的生成后清理仍有很短的时间段中生成的Java文件是世界看到。

Currently, I am using maven filtering and placeholders in my java code to create static constant classes but those classes are always visible in the target directory. A post-build cleanup of target still leaves a short time slot in which the resulting java file is visible to the world.

推荐答案

从你的描述，它听起来就像你正在谈论这不应该是在SCM仓库的关键，但需要被包含在最终的应用程序。 presumably的应用程序二进制不免费下载正因为如此，否则可能反正打开它，让你的钥匙，但如果构建结果只是被部署到某些服务器，这是好的。

From your description it sounds like you are talking about a key which should not be in the SCM repository, yet needs to be included in the final application. Presumably the application binary is not freely downloadable as such, or else anyway could open it up and get your key, but this is fine if the build result is simply being deployed to some server.

在这种情况下没有必要在具有该目标的关键present 目录（即詹金斯工作区），或甚至在建的文物有任何问题（例如： lastSuccessfulBuild /神器/目标/ myapp.war ），所以只要这些东西都不是公开可读。在CloudBees的DEV @云詹金斯实例的情况下，可以使用基于角色的访问控制，让公众看到为您的项目更改日志，也许是构建日志（审核他们做出不打印确认秘密之后）但拒绝访问工作区和文物。

In such a case there is not necessarily any problem in having the key present in the target directory (i.e. Jenkins workspace), or indeed in build artifacts (e.g. lastSuccessfulBuild/artifact/target/myapp.war), so long as these things are not publicly readable. In the case of a CloudBees DEV@cloud Jenkins instance, you can use role-based access control to allow the public to see the changelog for your project, and perhaps the build logs (after vetting them to make sure secrets are not printed), but deny access to the workspace and artifacts.

（至于神器读取权限而言，似乎除非詹金斯与 -Dhudson.security.ArtifactsPermission = TRUE 这是不是托管詹金斯一个选项可能是一个插件，需要创建使此权限，大概也是工作区涂掉权限，类似于现有的延伸阅读权限插件。工作区浏览权限是詹金斯的一个标准部分，至少，如果你不是这就够了归档文物而是直接在成功打造月底部署。）

(As far as artifact read permission is concerned, it seems that this is granted to anyone with overall read permission unless Jenkins is run with -Dhudson.security.ArtifactsPermission=true which is not an option for hosted Jenkins. Probably a plugin needs to be created which enables this permission, and probably also "workspace wipe-out" permission, akin to the existing Extended Read Permission plugin. Workspace browse permission is a standard part of Jenkins at least, which would suffice if you are not archiving artifacts but deploying directly at the end of a successful build.)

这篇关于如何能秘密API密钥，而使用公共构建服务器使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！