Ability to inject secrets into jobs about brigade

[bacongobbler]

Comment by bacongobbler
2017-07-04 15:39:37

---

This seems like it's already been implemented in the jobs API via the secrets object. I'll have to play around a bit more and see if I can come up with a job example for others.

[bacongobbler]

Comment by technosophos
2017-07-05 16:21:53

---

Actually, I really need some input into precisely that. What we do right now is allow the acid.js to map the keys in the Secret to an env var in the job. The acid.js does not actually have access to the values for the secret, though.

Sounds good on paper, but... this imposes a peculiar requirement on jobs: The configuration Secret has to be in the same namespace as the Job pod. That substantially hinders our ability to secure the environment.

So would it be better to pass in the key/value data from the secret into acid.js and then require Acid to explicitly send the values?

j = new Job('myjob');
j.secrets = {
  "DB_PASSWORD": e.project.dbPassword
}

[bacongobbler]

Comment by technosophos
2017-07-05 16:22:27

---

Also see #48

[bacongobbler]

Comment by bacongobbler
2017-07-05 17:27:16

---

The configuration Secret has to be in the same namespace as the Job pod. That substantially hinders our ability to secure the environment.

I don't entirely think that's a massive issue. Consider that the user writing (or administrating) the Job is the one that put that secret there. I think it'd make sense to have the two paired together, but I'm curious to hear what you mean when it'd hinder our ability to secure the environment.

In my view, the biggest security problems come from repos with .travis.yaml and having the PRs open to the public. Consider the following:

• anonymous user forks the project
• anon writes some code to print sensitive secrets, destroy the cluster environment, cause general mayhem
• anon makes a PR against the project with the malicious code

From experience the best way to circumvent this is to have a whitelist feature to ensure only trusted PRs can be tested, e.g. in a comment from a (github) project owner:

"@ci-bot OK to test"

I think I'm starting to get off topic from the original issue so maybe this should be a separate discussion around CI security.

Anyways...

So would it be better to pass in the key/value data from the secret into acid.js and then require Acid to explicitly send the values?

I think this would be a great UX! Perhaps something like this, amending the installation guide a bit when setting up a project:

First, let's create a new project and point it to the GitHub project https://github.com/technosophos/zolver

We'll create the simplest config file possible:

my-project.yaml:

project: "technosophos/zolver"
repository: "github.com/technosophos/zolver"
# Used by GitHub to compute hooks.
# TODO: MAKE SURE YOU CHANGE THIS. It's basically a password.
- secret: "MySuperSecret"
+ githubSecret: "MySuperSecret"
+ projectSecrets:
+   DB_PASSWORD: "mydatabasepassword" 

Anything under the projectSecrets field will be injected into the project secret, which can then be used in acid.js:

j = new Job('myjob');
j.image = 'myimage'
j.env.DB_PASSWORD = e.project.secrets.DB_PASSWORD

So in a way I am agreeing with you, but tweaking the UX a little bit to demonstrate how a user would inject these secrets using the acid-project chart's values.yaml file.

[bacongobbler]

Comment by technosophos
2017-07-06 22:50:14

---

So I guess I am thinking that, all things being equal, the least trusted entity may in fact be 3rd party Docker images. For that reason, we might want to run an entire build in its own namespace (perhaps with the relevant RBAC configuration). Since the Secret holds all of the project configuration, we want that to be in Acid's namespace (not the build's namespace). That's why I was thinking that maybe we'd have acid load the secret, expose the values to the JS file, and let the JS file pluck out what it needs.

In that model:

(a) A Docker image would never have access to the Acid Secret object directly (good!)

(b) The running build could be kept isolated from the rest of the cluster (good)

(c) but we'd have to let the Acid.js file have access to the contents of the secret (maybe bad?)

I agree with your other mitigating steps to prevent rogue CI runs.

[bacongobbler]

Comment by bacongobbler
2017-07-06 23:57:14

---

I agree with that model.

[bacongobbler]

Comment by technosophos
2017-07-08 00:02:45

---

I think I have come up with a workable version of the above that changes (c) to only include SOME parts of the secret.

I repartitioned the acid-project secret to have an env: object, which can contain arbitrary name/value pairs. Then just the env part is exposed to acid.js

$ helm install acid-project --set env.dbPassword = foo

Now in acid.js:

events.push = function(e) {
  j = new Job("foo")
  // j will get the password as $DB_PASSWORD
  j.env = { "DB_PASSWORD": e.env.dbPassword }
  j.run()

  // Since we didn't pass anything in env, j2 won't have access to any of the secret data.
  j2 = new Job("bar")
  j2.run()
}

But the downside to this is that the Pod that is running j will have pod.spec.container.env[DB_PASSWORD] set to the cleartext password.

[bacongobbler]

Comment by jchauncey
2017-07-09 15:03:39

---

I mentioned this in #68 but it really should have been said here.

You may want to consider how you would scrub log output of sensitive data (or truncate it so you could at least validate that it looks correct).