[Ansible-service-broker] cluster-role escalation

[John Matthews]

On Wed, Jan 31, 2018 at 2:30 PM, Mo Khan <monis at redhat.com> wrote:

> Just to be clear, I am extremely uncomfortable in giving the ASB any more
> powers.  If you want a broker that can manipulate cluster resources, it
> needs to be completely separated from the standard ASB broker that handles
> user requests.  A better approach will likely involve the user giving the
> ASB a token that it then uses to perform actions (i.e. the user must have
> the powers needed to perform those actions but the ASB itself does not).
>

Totally agree, no objections.
Think of the work happening now is R&D effort focused on APB development
for future of how cluster infrastructure APBs can be developed.

The larger problem of proper permissions for cluster infrastructure has not
been researched yet.
That is future work we have yet to begin.




>
> Ryan is correct on the scoping of bindings and the escalation checks.
>
> On Wed, Jan 31, 2018 at 1:44 PM, Ryan Hallisey <rhallise at redhat.com>
> wrote:
>
>> Following up on my original post.  I found the reason the rolebinding
>> was failing to create the cluster-admin role.  My broker service
>> account was not a cluster-admin. This makes sense since you shouldn't
>> be able to elevate to higher permissions that you are.  However,
>> adding the cluster-admin role to apb does not provide cluster level
>> access. Since we're creating a role binding, the apb is granted
>> cluster-admin permissions within it's namespace. In order to access
>> cluster level resources (anything outside it's namespace), we need to
>> create a clusterrolebinding.
>>
>> Here's a writeup for adding a feature that will allow developers to
>> have full access to the cluster:
>> https://github.com/openshift/ansible-service-broker/issues/715
>>
>> -Ryan
>>
>> On Wed, Jan 31, 2018 at 11:20 AM, Ryan Hallisey <rhallise at redhat.com>
>> wrote:
>> > Thanks David, that's really good to know.
>> >
>> >
>> > On Wed, Jan 31, 2018 at 9:13 AM, David Zager <dzager at redhat.com> wrote:
>> >> Ryan,
>> >>
>> >> My understanding of wanting to run APBs with extra privileges from our
>> >> broker is that this is a feature we would like to support down the
>> line. As
>> >> an aside, it seems worth pointing out that you can workaround this
>> issue by
>> >> using docker run like:
>> >>
>> >> docker run --rm --net=host \
>> >>   -v $HOME/.kube:/opt/apb/.kube:z \
>> >>   -u $UID \
>> >>   ${APB_NAME} ${APB_ACTION:-'provision'} \
>> >>   --extra-vars "namespace=mycoolnamespace" \
>> >>   --extra-vars "etc=etc"
>> >>
>> >>
>> >> Notes on this command:
>> >>
>> >> You need to be using your host's network stack (--net=host)
>> >> Passing your kube config allows the APB to run at your permission
>> level (ie.
>> >> if you are an cluster-admin you can do what you want).
>> >> APB_NAME in this case would be kubevirt-apb
>> >> You may or may not need the namespace argument, I just know that a lot
>> of
>> >> our existing APBs assume that the  namespace already exists
>> >>
>> >> I am a huge fan of the idea of using APBs to manage a cluster outside
>> the
>> >> service-catalog/service-broker context. However, I am also excited
>> about
>> >> pursuing the extra privileged APBs in our broker and how we will meet
>> that
>> >> use case, so this is not meant to take away from that discussion.
>> >>
>> >> Thanks,
>> >> David
>> >>
>> >> On Wed, Jan 31, 2018 at 6:13 AM John Matthews <jmatthew at redhat.com>
>> wrote:
>> >>>
>> >>> Mo,
>> >>>
>> >>> Do you have any thoughts on the issue Ryan mentions below on being
>> unable
>> >>> to create a rolebinding that is cluster-admin?
>> >>> For background, this is for enabling the Broker to deploy APBs that
>> will
>> >>> modify cluster infrastructure...not a typical application/service but
>> >>> special APBs that require extra privileges.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Jan 30, 2018 at 9:56 PM, Ryan Hallisey <rhallise at redhat.com>
>> >>> wrote:
>> >>>>
>> >>>> Karim,
>> >>>>
>> >>>> I think I have a workaround patch that will get provision working for
>> >>>> the kubevirt-apb.  Instructions for how to test it are in the commit
>> >>>> message.
>> >>>>
>> >>>>
>> >>>> https://github.com/rthallisey/ansible-service-broker/commit/
>> f27e0538959c43d47d2ff80bba1e894f2249ad62
>> >>>>
>> >>>> To summarize for folks what I think is happening. We need the apb to
>> >>>> have the cluster-admin role so it can create cluster-roles.  To do
>> >>>> this, set sandbox_role: cluster-admin, auto_escalate: true, and make
>> >>>> the asb user cluster-admin.  Then when you provision, you'll hit this
>> >>>> issue: https://github.com/openshift/ansible-service-broker/issues/7
>> 11.
>> >>>> The rolebinding fails to create with the error:
>> >>>>   rolebindings.rbac.authorization.k8s.io
>> >>>> "apb-9c21c424-7091-4bc1-b5c5-0caa08aeec39" is forbidden: attempt to
>> >>>> grant extra privileges.
>> >>>> It seems that we can't create a rolebinding that is cluster-admin.
>> >>>> I'm still exploring for the reason why it fails, but my theory is
>> that
>> >>>> the cluster-admin role gives access outside the scope of a role so it
>> >>>> requires a clusterrolebinding. With the clusterrolebinding created
>> >>>> with cluster-admin permissions, I was able to create
>> cluster-resources
>> >>>> from the apb.
>> >>>>
>> >>>> Thanks,
>> >>>> -Ryan
>> >>>>
>> >>>> _______________________________________________
>> >>>> Ansible-service-broker mailing list
>> >>>> Ansible-service-broker at redhat.com
>> >>>> https://www.redhat.com/mailman/listinfo/ansible-service-broker
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Ansible-service-broker mailing list
>> >>> Ansible-service-broker at redhat.com
>> >>> https://www.redhat.com/mailman/listinfo/ansible-service-broker
>> >>
>> >>
>> >> _______________________________________________
>> >> Ansible-service-broker mailing list
>> >> Ansible-service-broker at redhat.com
>> >> https://www.redhat.com/mailman/listinfo/ansible-service-broker
>> >>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ansible-service-broker/attachments/20180131/80ba7596/attachment.htm>