[Strimzi] Multiple namespace AMQ

[Jakub Scholz]

I would perhaps just add one more thing ... if you replace the RoleBindings
in the installation files with ClusterRoleBindings, you will not need to
change the RBAC for every new namespace. You will just need to modify the
namespaces (support for listening automatically in all namespaces is in
progress: https://github.com/strimzi/strimzi-kafka-operator/pull/1261) in
the deployment - that should not require cluster-admin rights. But that of
course means that you will give the operator access to your whole cluster.
So it is a bit trade-off between security and user comfort. I'm afraid it
is sometimes hard to combine everything ... user-friendliness, security,
features into single package.

Thanks & Regards
Jakub

On Wed, Jan 30, 2019 at 9:08 AM Paolo Patierno <ppatiern at redhat.com> wrote:

> Hi Daniel,
>
> the Cluster Operator needs these rights in order to watch/create/update
> all the Kubernetes/OpenShift resources for deploying and managing one or
> more Kafka clusters (and Kafka Connect, Mirror Maker instances).
> It also needs the rights for delegating to the other operators (User and
> Topic) the rights for handling the other resources for users and topics
> management.
> Giving these rights using a service account and role bindings is not
> possible without admin rights.
> With OpenShift 3.11 and the OLM (Operators Lifecycle Manager) in place, it
> should be simpler and transparent to the final user; the OLM will take care
> of deploying the Cluster Operator so that admin rights aren't needed
> anymore.
> Finally just remember that, in order to deploy a Kafka cluster, you don't
> need admin rights anymore. In that case a "Strimzi admin" role is enough
> for creating the Kafka related resources (as you can read here
> https://strimzi.io/docs/master/#assembly-getting-started-strimzi-admin-str
> ).
>
> Thanks,
> Paolo.
>
> On Tue, Jan 29, 2019 at 3:08 PM Daniel Beilin <dandaniel97 at gmail.com>
> wrote:
>
>> Hello,
>>
>> I want to deploy AMQ streams in such a way where we have one Cluster
>> operator sitting inside one project and other projects use it in order to
>> deploy their clusters. But the way it seems to work is not very "as a
>> service" and requires a cluster admin involvement in several places in
>> order to add a new project.
>>
>> Firstly, you need to change the env inside the deployment of the cluster
>> operator.
>> Secondly, you need to use the role binding in the new project
>> Thirdly, you need to re-deploy the cluster operator.
>>
>> These three steps require high privilege and not really accessible for
>> someone who is not a cluster admin, is there a way to make this more
>> accessible not to cluster admin? Or a way you don't need to do this for
>> every single project?
>>
>> Thank you in advanced,
>> Daniel
>> _______________________________________________
>> Strimzi mailing list
>> Strimzi at redhat.com
>> https://www.redhat.com/mailman/listinfo/strimzi
>>
>
>
> --
>
> PAOLO PATIERNO
>
> PRINCIPAL SOFTWARE ENGINEER, MESSAGING & IOT
>
> Red Hat
>
> <https://www.redhat.com/>
> <https://red.ht/sig>
> <https://redhat.com/summit>
> _______________________________________________
> Strimzi mailing list
> Strimzi at redhat.com
> https://www.redhat.com/mailman/listinfo/strimzi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/strimzi/attachments/20190130/9487c698/attachment.htm>