<div dir="ltr"><div dir="ltr">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: <a href="https://github.com/strimzi/strimzi-kafka-operator/pull/1261">https://github.com/strimzi/strimzi-kafka-operator/pull/1261</a>) 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.</div><div dir="ltr"><br></div><div>Thanks & Regards</div><div>Jakub</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 30, 2019 at 9:08 AM Paolo Patierno <<a href="mailto:ppatiern@redhat.com">ppatiern@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Daniel,<div><br></div><div>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).</div><div>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.</div><div>Giving these rights using a service account and role bindings is not possible without admin rights.</div><div>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.<br></div><div>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 <a href="https://strimzi.io/docs/master/#assembly-getting-started-strimzi-admin-str" target="_blank">https://strimzi.io/docs/master/#assembly-getting-started-strimzi-admin-str</a>).<br></div><div><br></div><div>Thanks,</div><div>Paolo.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 29, 2019 at 3:08 PM Daniel Beilin <<a href="mailto:dandaniel97@gmail.com" target="_blank">dandaniel97@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Hello, </div><div dir="auto"><br></div>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. <div dir="auto"><br></div><div dir="auto">Firstly, you need to change the env inside the deployment of the cluster operator. </div><div dir="auto">Secondly, you need to use the role binding in the new project </div><div dir="auto">Thirdly, you need to re-deploy the cluster operator. </div><div dir="auto"><br></div><div dir="auto">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? </div><div dir="auto"><br></div><div dir="auto">Thank you in advanced, </div><div dir="auto">Daniel</div></div>
_______________________________________________<br>
Strimzi mailing list<br>
<a href="mailto:Strimzi@redhat.com" target="_blank">Strimzi@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/strimzi" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/strimzi</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-838399205943663040gmail_signature"><div dir="ltr"><div><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>PAOLO</span> <span>PATIERNO</span></p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>PRINCIPAL SOFTWARE ENGINEER, MESSAGING & IOT</span></p><p style="font-family:overpass,sans-serif;margin:0px;font-size:10px;color:rgb(153,153,153)"><a href="https://www.redhat.com/" style="color:rgb(0,136,206);margin:0px;text-decoration:none" target="_blank">Red Hat <span><br><br></span></a></p><table border="0" style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"><img src="https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png" width="90" height="auto"></a></td><td style="font-size:10px"><div><a href="https://redhat.com/summit" style="text-decoration:none" target="_blank"><img width="70px" height="auto" src="https://www.redhat.com/cms/managed-files/summit_logo_170_0.png" style="outline: 0px;"></a></div></td></tr></tbody></table></div></div></div></div>
_______________________________________________<br>
Strimzi mailing list<br>
<a href="mailto:Strimzi@redhat.com" target="_blank">Strimzi@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/strimzi" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/strimzi</a><br>
</blockquote></div>