Update the RBAC templates for the peering objects & their scopes

docs/deployment-rbac.yaml

@@ -2,6 +2,7 @@
 apiVersion: v1
 kind: ServiceAccount
 metadata:
+  namespace: "{{NAMESPACE}}"
   name: kopfexample-account
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
@@ -12,20 +13,26 @@ rules:
 
   # Framework: knowing which other operators are running (i.e. peering).
   - apiGroups: [zalando.org]
-    resources: [kopfpeerings]
+    resources: [clusterkopfpeerings]
     verbs: [list, watch, patch, get]
 
-  # Application: watching & handling for the custom resource we declare.
+  # Application: read-only access for watching cluster-wide.
   - apiGroups: [zalando.org]
     resources: [kopfexamples]
     verbs: [list, watch]
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: Role
 metadata:
+  namespace: "{{NAMESPACE}}"
   name: kopfexample-role-namespaced
 rules:
 
+  # Framework: knowing which other operators are running (i.e. peering).
+  - apiGroups: [zalando.org]
+    resources: [namespacedkopfpeerings]
+    verbs: [list, watch, patch, get]
+
   # Framework: posting the events about the handlers progress/errors.
   - apiGroups: [events.k8s.io]
     resources: [events]
@@ -61,6 +68,7 @@ subjects:
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: RoleBinding
 metadata:
+  namespace: "{{NAMESPACE}}"
   name: kopfexample-rolebinding-namespaced
 roleRef:
   apiGroup: rbac.authorization.k8s.io

docs/deployment.rst

@@ -77,17 +77,20 @@ The pod where the operator runs must have the permissions to access
 and to manipulate the objects, both domain-specific and the built-in ones.
 For the example operator, those are:
 
-* ``kind: KopfPeering`` for the cross-operator awareness.
+* ``kind: ClusterKopfPeering`` for the cross-operator awareness (cluster-wide).
+* ``kind: NamespacedKopfPeering`` for the cross-operator awareness (namespace-wide).
 * ``kind: KopfExample`` for the example operator objects.
-* ``kind: Pod/Job/PersistentVolumeClaim`` as the children objects.
+* ``kind: Pod/CluJob/PersistentVolumeClaim`` as the children objects.
 * And others as needed.
 
 For that, the RBAC_ (Role-Based Access Control) could be used
 and attached to the operator's pod via a service account.
 
 .. _RBAC: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
 
-Here is an example of what a RBAC config should look like:
+Here is an example of what a RBAC config should look like
+(remove the parts which are not needed: e.g. the cluster roles/bindings
+for the strictly namespace-bound operator):
 
 .. literalinclude:: deployment-rbac.yaml
     :caption: rbac.yaml
@@ -104,7 +107,7 @@ And the created service account is attached to the pods as follows:
     :name: deployment-service-account-yaml
 
 
-The service accounts are always namespace-scoped.
+Please note that the service accounts are always namespace-scoped.
 There are no cluster-wide service accounts.
 They must be created in the same namespace as the operator is going to run in
-(even if it is going to server the whole cluster).
+(even if it is going to serve the whole cluster).