Make router, registry, deployer use secrets

[liggitt]

No description provided.

[liggitt]

[test]

[liggitt]

@pmorie can you take a look at the secrets usage to make sure I'm not doing anything insane. The interesting commit is the last one - the rest is the rebase and auth changes in other pulls I'm basing off of.

I'm decently satisfied with the registry/router/deployer setups for the moment.

The next step is to get a command that can turn a .kubeconfig or similar into a secret, for use with things like the Jenkins pod that need API credentials. The namespace defaulting would help a lot there, so our jenkins example could pre-set a volumemount and volume which referenced a secret named "jenkins-secret", and tell them to create such a secret in the namespace prior to creating the Jenkins pod.

[pmorie]

@liggitt started taking a look tonight on my phone, need a real screen for
a diff this robust

On Mon, Mar 2, 2015 at 10:54 PM, Jordan Liggitt notifications@github.com
wrote:

@pmorie https://github.com/pmorie can you take a look at the secrets
usage to make sure I'm not doing anything insane. The interesting commit is
the last one - the rest is the rebase and auth changes in other pulls I'm
basing off of.

I'm decently satisfied with the registry/router/deployer setups for the
moment.

The next step is to get a command that can turn a .kubeconfig or similar
into a secret, for use with things like the Jenkins pod that need API
credentials. The namespace defaulting would help a lot there, so our
jenkins example could preset a volumemount and volume which referenced a
secret named "jenkins-secret", and tell them to create such a secret in the
namespace prior to creating the Jenkins pod.

—
Reply to this email directly or view it on GitHub
#1208 (comment).

[smarterclayton]

Jeff added just such a command upstream yesterday (as a pull).

[liggitt]

rebased

[smarterclayton]

Isn't this going to break as soon as we add service accounts?

[liggitt]

yeah, started this before we talked through service account mapping to secrets

[smarterclayton]

Up to you whether you want to land it now or hold it. If it substantially reduces confusion I'm all for doing it now.

----- Original Message -----

yeah, started this before we talked through service account mapping to
secrets

---

Reply to this email directly or view it on GitHub:
#1208 (comment)

[pmorie]

Nit: mount_path -> mountPath

[liggitt]

Fixed

[pmorie]

@smarterclayton @liggitt I don't think just service accounts would affect this - you would consume the secrets in the same way unless there was a LOAS daemon that decorated your requests to the master with auth. Am I missing something?

[liggitt]

@pmorie we're talking about restricting a pod's access to a secret unless it is assigned a service account which also has access to the secret. double references aren't ideal, but we're having a hard time figuring out a different way to subdivide secret ACL within a namespace

[smarterclayton]

If secret is the reference and service account is the check, then it's probably ok to put the volumes in now. I don't think the current setup will match the experience we want for end users (expose secret when it's added to the account).

On Mar 10, 2015, at 4:52 AM, Jordan Liggitt notifications@github.com wrote:

@pmorie we're talking about restricting a pod's access to a secret unless it is assigned a service account which also has access to the secret. double references aren't ideal, but we're having a hard time figuring out a different way to subdivide secret ACL within a namespace

—
Reply to this email directly or view it on GitHub.

[openshift-bot]

continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_openshift3/1792/)

[openshift-bot]

Evaluated for origin up to bf8c15f

[openshift-bot]

Origin Action Required: Pull request cannot be automatically merged, please rebase your branch from latest HEAD and push again

[liggitt]

closing, will rework with service accounts