[Ansible-service-broker] Fwd: Thoughts on dynamic svc accounts

[Erik Nelson]

I'm forwarding my original message to the list because it really
should have been sent here in the first place and I can't seem to get
gmail to forward the thread...

RFC.


---------- Forwarded message ----------
From: Erik Nelson <ernelson at redhat.com>
Date: Wed, Jun 7, 2017 at 9:01 PM
Subject: Thoughts on dynamic svc accounts
To: John Matthews <jmatthew at redhat.com>
Cc: Jesus Rodriguez <jesusr at redhat.com>, tsanders <tsanders at redhat.com>


John et.al.,

Had some success creating k8s resources using client libs from within
the broker today. I've got an idea where I *think* we need to go, so I
wanted to run that by you to make sure it makes sense and also have
some q's about the implementation.

First, "Bindings" are used to associate Roles to
users/groups/serviceaccounts. Speaking briefly with Paul, we need to
use RoleBindings instead of ClusterRoleBindings, difference being
RoleBindings are scoped to a specific project, so an apb would be
authorized to act within its requested namespace, but no others.
Looking over the default roles, we should be able to lock things down
to the *edit* level for our apbs. This means they can't write to Roles
or RoleBindings to affect permissions within the namespace, but can
read/write other resources within the namespace. I can see a case for
relaxing this, but it's a good thing to bring up for discussion:

https://kubernetes.io/docs/admin/authorization/rbac/#default-roles-and-role-bindings

Here are my current thoughts, would really like feedback to see if
this makes sense:

RoleBindings scope permissions within a project. Pods running apb
actions are authorized within a project via the serviceaccounts they
run as (which are authorized by their project scoped RoleBindings).
Based on this, **it feels like everything should be scoped within the
requested namespace that's passed into the broker**. That means the
broker needs to create the project if it doesn't already exist, create
a ServiceAccount scoped to the namespace, assign the edit role to that
ServiceAccount scoped to the namespace, then run the apb action as a
Pod scoped to that namespace as the newly created service account.

Significant changes here are:
* Broker needs to create the requested project if it doesn't already exist
! * APBs are run inside of the requested project, not ansible-service-broker
* APBs are strictly authorized to whatever permissions the RoleBinding
grants the ServiceAccount identity for the life of the ServiceAccount.
  APB ServiceAccounts exist temporarily until the broker destroys the
ServiceAccount at the conclusion of the APBs pod action.

Q's
-> Does this make sense to you?
-> If this is what we need to do, everything above is vanilla k8s
except Projects, and we generally are talking about Projects when
discussing things like where APBs need to run. I hear people use
Project and Namespace interchangeably (I did so throughout this mail),
but I don't think that's actually fair. A Project is not a Namespace,
it's a superset that's a strict OCP concept. I can't create a Project
from the k8s client.
  + If I need to create a Project to scope this work in OCP, I don't
know how to interface with OCP from go. I only have an interface into
k8s. Do I need a unique Openshift client?
  + When scoping these k8s objects, can I reference a Namespace that
shares its name with a Project created with the Openshift client? i.e,
if I create a Project, I get a Namespace with the same name ID for
free?

Please challenge anything you see here that doesn't make sense, and if
it does, looking for people to help me answer these questions.

NOTE: This is entirely separate from the broker's service account. I
think I've got a decent handle on how to deal with that, so trying to
ferret out the unknowns around dynamic apb svcaccts.

NOTE++: Reading again, sorry for the wall of text. Kind of a brain dump :)

- Erik