https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rke2
a
This message was deleted.
c
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
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
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
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
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.
49 Views
Open in Slack
PreviousNext
Powered by