https://rancher.com/ logo
#rke2
Title
# rke2
a

adamant-kite-43734

01/27/2023, 12:15 PM
This message was deleted.
c

creamy-pencil-82913

01/27/2023, 5:20 PM
It should work for all the CNIs that come with rke2. Only the one of them requires an additional namespace, the others just use kube-system.
b

best-microphone-20624

01/28/2023, 5:45 AM
I was under the impression that the Calico tigera-operator installed privileged Calico workloads into both the
calico-system
and
calico-apiserver
namespaces. Did I get that wrong for RKE2?
Hi @creamy-pencil-82913 For example, the
calico-node
Daemonset deployed to the
calico-system
namespace runs with
securityContext.privileged: true
.` This seems problematic for the Restricted profile. As a result, shouldn't this namespace be included in the namespace exemptions list?
According to the helm chart link below, the rke2 calico chart disables the calico apiServer by default. Since it is possible to override the default, would it make sense to consider adding namespace
calico-apiserver
to the exemption list as well just in case. Thoughts? https://github.com/rancher/rke2-charts/blob/dbade3fffd47efcf5ad28f11f8cc3216e50632[…]/packages/rke2-calico/generated-changes/patch/values.yaml.patch,
c

creamy-pencil-82913

02/01/2023, 8:50 PM
as far as I know we’ve not seen that to be necessary
I believe that’s because the Tigera operator itself handles adding the correct pod-security labels to the namespace. That’s the preferred way to manage that, as opposed to hardcoding the namespaces in the PSA config
Copy code
brandond@dev01:~$ kubectl get namespace calico-system -o yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2023-02-01T20:49:06Z"
  labels:
    <http://kubernetes.io/metadata.name|kubernetes.io/metadata.name>: calico-system
    name: calico-system
    <http://pod-security.kubernetes.io/enforce|pod-security.kubernetes.io/enforce>: privileged
    <http://pod-security.kubernetes.io/enforce-version|pod-security.kubernetes.io/enforce-version>: latest
  name: calico-system
  ownerReferences:
  - apiVersion: <http://operator.tigera.io/v1|operator.tigera.io/v1>
    blockOwnerDeletion: true
    controller: true
    kind: Installation
    name: default
    uid: 37ca9fde-175a-4d75-83f4-1cb9bb0af38e
  resourceVersion: "835"
  uid: 1a56a63b-d54e-436c-a5d1-d52cf8b155c3
spec:
  finalizers:
  - kubernetes
status:
  phase: Active
so yeah, not necessary
the operator should do the same for the apiserver namespace, if it creates it
b

best-microphone-20624

02/01/2023, 8:59 PM
Any idea when this behavior was added to the Tigera operator? Do you know if this behavior applies to all 1.23+ RKE2 versions, regardless whether cis-mode is enabled or not?
c

creamy-pencil-82913

02/01/2023, 9:03 PM
no, I don’t know when the tigera operator added that behavior. I’d defer to the Tigera folks on that.
I suspect that newer releases just add the labels unconditionally, since there’s no harm in having them even if PSA isn’t enabled.
41 Views