<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Daniel,<div><br></div><div>I think that will not work well, because we reference some of these ClusterRoles in the service accounts which we create for the Kafka brokers. If it works then the features might be definitely limited. For sure I would say the Topic and User operators will not work and exposing NodePorts and Kafka rack awareness will not work. Maybe something more as well.</div><div><br></div><div>The ClusterRoles do not really give us access to the whole cluster. For most of them, we use only RoleBindings to bind them to our service accounts. So despite using ClusterRoles, we get only the rights within a namespace as if these would be regular Roles. But we do not need to create the Role in every single namespace we need to use because the ClusterRoles are global. </div><div><br></div><div>We use ClusterRoleBindings only for two ClusterRoles:</div><div>- 030-ClusterRole-strimzi-kafka-broker.yaml which gives us the possibility to read nodes</div><div>- 021-ClusterRole-strimzi-cluster-operator-role.yaml which we need to be able to create ClusterRoleBindings</div><div>We need to use ClusterRoles and ClusterRoleBindings here, because these resources are cluster wide and you cannot grant them without using ClusterRoles and ClusterRoleBindings. If you don't deploy these, Strimzi will work fine unless you try to use Kafka rack-awareness or expose it using Node Ports.</div><div><br></div><div>I would also like to point out that although we have the ability to create RoleBindings and ClusterRoleBindings, we cannot give our self any additional rights. Kubernetes have protection against privilege escalation. So we can create only RoleBindings and ClusterRoleBindings which contain the rights which the Cluster operator already has. So the Strimzi operator cannot grant it self access rights for a different namespace or anything like that.</div><div><br></div><div>Thanks & Regards</div><div>Jakub</div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 28, 2018 at 3:39 PM Daniel Beilin <<a href="mailto:dandaniel97@gmail.com">dandaniel97@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hello, in order to deploy strimzi you need to create a cluster role, which can be a possible point for attacks, because you can get the permissions to the whole cluster. My question is: can you change the cluster role to a regular role without interfering with the rest of the deployment? In other words, <div dir="auto">If in my deployment we will change the cluster roles and role bindings in order to allow the service account the same access as before, but this time with just a normal role, will it cause any problems when trying to deploy a cluster on this spasific namespace? <br><div dir="auto"><br></div><div dir="auto">Best regards, </div><div dir="auto">Daniel </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>