Creating clusters in other namespaces than default? about mysql-operator HOT 7 CLOSED

Hi @kirreen,

This is a little clunky and poorly documented at the moment.

Perhaps the best approach would be for the operator to create the required service account and role binding on cluster creation (thoughts @owainlewis?).

Prior to that being implemented you can set a custom namespace when installing via helm using --set operator.namespace=my-namespace. That will install the operator into that namespace, create the service account and role binding in the desired namespace, and allow you to create clusters in that namespace.

Alternatively, you can create the service accont and role binding manually for individual namespaces as follows (presumes the mysql operator was installed global mode):

$ cat <<EOF | kubectl create -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mysql-agent
  namespace: my-namespace
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: mysql-agent
  namespace: my-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: mysql-operator
subjects:
- kind: ServiceAccount
  name: mysql-agent
  namespace: my-namespace
EOF

from mysql-operator.

Thanks, creating the serviceaccount and rolebinding in each new namespace is closer to what I wanted for my use case.

from mysql-operator.

why do the mysql pod need to be run under the mysql-agent service account?
also the mysql-agent service account is give the mysql-operator role which is very powerful:

rules:
  - apiGroups:
    - "*"
    resources:
    - "*"
    verbs:
    - "*"

this would be unacceptable in any realistic enterprise deployment. Why is this needed?
I think the mysql operator should be able to deploy a mysql cluster in any namespace by default, so the mysql-agent sa (if needed) should be created when the mysql cluster is requested.

from mysql-operator.

Hi @raffaelespazzoli,

Agree wholeheartedly and certainly very high up on the priority list. What we've got currently RBAC/SA wise is just a first pass at getting something working and certainly needs to be tied down for a production deployment.

The mysql-agent doesn't need the same privialages as the mysql-operator. We'll need to add a separate ClusterRole. We've discussed creating the SA on cluster creation, however, that would require the operator to have a superset of the permissions that the mysql-agent requires voilating the principle of least privilage. I'm not completely sold either way though as the operator currently does require a superset of the permissions that the agent requires and from a UX perspective creating the SA is the more arractive option.

from mysql-operator.

@prydie allowing the operator to create SA is not a good idea. IMHO, the best approach here is for SA (for agent and cluster) to be created by k8s admin and specified in spec.serviceAccount in MySQLCluster resource. Creating SA and binding it to a role is a super simple operation so the UX experience will not be impacted too much by this. At the same time this aproach, it is very elastic from a security point of view.

@raffaelespazzoli here are my RBAC policies, with separated roles for mysql-agent and mysql-operator.

https://gist.github.com/gites/d7ce470e36a5d43259b6e31f23d46e89

from mysql-operator.

@prydie @gites I think the mysql-operator role should be a ClusterRole so that it can operate on all the namespaces.
With regard to the mysql-agent role, can you make an example of why so many permissions are needed?
The general expectations from the opetrator pattern is that the created pods will be able to run with the default service account, which means with basically no permissions against the Kubernetes API. After all these are the mysql pods and ancillary pods, why do they need to access the Kubernetes API?

from mysql-operator.

Documented here now: https://github.com/oracle/mysql-operator/blob/master/docs/tutorial.md#create-a-simple-mysql-cluster

from mysql-operator.