Greetings is it expected that the psa exemption namespaces l rancher-users #rke2

Title

best-microphone-20624

01/27/2023, 12:15 PM

Greetings, is it expected that the psa exemption namespaces listed in the following link should support all CNIs or just the default canal CNI? https://github.com/rancher/rke2/blob/0ab4614b13daa5a49e484249a49012918d46ed22/pkg/rke2/psa.go#L58

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.

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,

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

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

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?

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.

14 Views

#rke2 Join Slack