The only update instructions for ECK that i've found are just kubectl apply -f and you're good to go. It's not that simple. For example I install the operator in specific namespaces because I don't want the operator to have access to all the namespaces. So when I do an update to CRDs it's going to update the CRDs for all the different operators in the various namespaces. I've tried to separate the install for different namespaces but it's not easy when the yaml has part CRDs that apply to all namespaces and then the actual operator install with roles, etc that are tied to a specific namespace.
It would be helpful if there was upgrade instructions for people that run the operator in specific namespaces.
As more people are aware of the security implications of CRDS and choose to run the operator in specific namespaces more people will have this problem.
My specific problem is I'm upgrading to 1.2.1 and I saw there are new Kinds 'Beats' and so now I need to update the CRDs but I don't want to adversely affect anything. And I may have a scenario where one operator in namespace A is running operator v 1.1.1 and another one say operator B is running operator 1.2.1. If I update the CRDs will they both be ok? And I have to dig through the yaml to separate the CRDs from the Operator and roles because the CRDs apply to globally but the Operator and roles are applied at the namespace level. Again this is all done for security reasons. I'd love to just run kubectl apply -f all-in-one and be done with it. But if I allow the operator to have global access I'm told that's a big security hole.
For adding new CRDs, older versions of the operator are not aware of the new types so will not take any action on resources of that type. In general I would not recommend upgrading CRDs until you can upgrade all instances of the operator. This is one of the downsides of CRDs being cluster scoped, which is not likely to change in k8s any time soon.
We do not test forwards compatibility with CRDs, though unless there are breaking changes flagged in the release notes the operator should work even if CRDs are updated to a newer version. Again I would recommend upgrading all instances of the operator along with the CRDs.
I am not sure what security implications you mean overall. Often, we see people deploy operators into individual namespaces because they do not have access to the whole cluster (normally shared across an organization). If you do not have similar organizational restrictions you can run a single operator, and either grant it access to all namespaces or scope it only to specific namespaces. Running multiple instances of the same operator is not really more secure on its own, it is more the outcome of other organizational rules.
As far as the upgrade not being as simple as kubectl apply, in my view the process is pretty similar so I am not sure how we could make this clearer. The upgrade process is identical to the original install process -- download the yaml, make the necessary modifications to suit your needs (specific namespace etc), and kubectl apply.
This should become simpler for at least helm users in the future as you can reuse values files between versions.
Yes i'll try to update the operators at the same time I update the CRDs. I separate the CRD part of the yaml from the namespace and below because I run the operator in multiple namespaces.
If you don't run it with namespace scoped then it's cluster scoped and has access to the WHOLE cluster. If it's hacked then the whole cluster is exposed. My security folks don't allow this.
Now that i'm familiar with the yaml it's pretty clear there's a CRD section and then the specific namespace section at the bottom. I just separate these parts myself.
If you don't run it with namespace scoped then it's cluster scoped and has access to the WHOLE cluster. If it's hacked then the whole cluster is exposed. My security folks don't allow this.
You can scope ECK to multiple namespaces and not the whole cluster, there's no need necessarily for 1:1 operator:namespace mapping is what I was trying to communicate.
It's not clear to me how you'd make it namespace scoped but still have permissions to reach into other namespaces to perform operations. When you create service accounts and rolebindings they have a namespace and they are limited to that namespace.
the namespaces flag. You can reference serviceaccounts in other namespaces in rolebindings to allow a single service account access to multiple namespaces without using clusterroles.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.