Add Seccomp default profile to managed apps and core components

[pipo02mix]

Is your feature request related to a problem? Please describe.

Kubernetes allow setting Seccomp profiles to their workloads. It is an extra security layer and some security benchmarks point to enable it as default

Describe the solution you'd like

Adding the default profile for all our managed components and the restricted PSP. Verify it is not affecting the behaviour of any component (maybe node exporter should be reviewed)

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
  annotations:
 seccomp.security.alpha.kubernetes.io/defaultProfileName:  'runtime/default'

Describe alternatives you've considered

Additional context

[puja108]

Can we find out what the actual runtime/default profile is that is on the machines? Would that be coming from the default flatcar config? /cc @giantswarm/sig-security

[nprokopic]

Here https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp it says:

runtime/default - The default container runtime profile is used.

And Docker seccomp docs state the following:

The default seccomp profile provides a sane default for running containers with seccomp and disables around 44 system calls out of 300+. It is moderately protective while providing wide application compatibility. The default Docker profile can be found here https://github.com/moby/moby/blob/master/profiles/seccomp/default.json.

I'm not sure if Flatcar is setting some other values there, but IIUC I don't think they would, since runtime/default should mean that default container runtime profile is used.

Not sure how switching to containerd would affect that, they have some default stuff here https://github.com/containerd/containerd/blob/master/contrib/seccomp/seccomp_default.go.

[puja108]

This would be only for our stuff right? If we hit those profile limits we might need to create seccomp profiles for our stuff.

[pipo02mix]

yes it is only for our stuff, but I would include the default profile for the restricted PSP, to have a default secure setting (do we need to see what differences are and if it will cause any harm to the users).

…

On Mon, Feb 1, 2021 at 3:20 PM Puja ***@***.***> wrote: This would be only for our stuff right? If we hit those profile limits we might need to create seccomp profiles for our stuff. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#259 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGZZ7KTWKERUGEFIX5C6ATS42ZUDANCNFSM4WZDVXLA> .

-- Fernando Ripoll Solution Engineer @ Giant Swarm GmbH +34 654525940 @fer (slack)

[nprokopic]

There are some changes here in the upstream.

kubernetes/enhancements#2413

Here is KEP-2413: Enable seccomp by default.

Motivation

Kubernetes provides a native way to specify seccomp profiles for workloads, which is disabled by default today. Seccomp adds a layer of security that could help prevent CVEs or 0-days if enabled by default. If we enable seccomp by default, we make implicitly Kubernetes more secure.

Proposal

We introduce a feature gate as well as corresponding kubelet flag that enables a seccomp for all workloads by default. There are a few options for what should be the default seccomp profile.

The most preferred solution is to promote the RuntimeDefault profile (previously the runtime/default annotation) to the new default one.

[puja108]

@stone-z would this be something that team shield could drive (you might even have sth similar already planned)?

[stone-z]

@stone-z would this be something that team shield could drive (you might even have sth similar already planned)?

Yep! This is in our backlog. There is already a policy requiring RuntimeDefault or Localhost included in the restricted PSS policies

[Strigix]

The use of the runtime/default seccomp profile has been tested on a MC and WC by setting it as the default for anything normally running undefined. Creating clusters was without problems, therefor setting the profile for the repos below, the list below are reported apps/components according to Kyverno alerts.

A checked box below either means:

• A seccomp profile is already in use. (Sometimes clusters run older app versions without them)
• A pull request has been made to enable the runtime/default seccompprofile

It does NOT mean it's released with the profile yet.

List:

• app-admission-controller
• app-exporter
• app-operator
• athena
• aws-admission-controller
• aws-collector
• aws-node-termination-handler-app
• aws-operator
• aws-pod-identity-webhook
• aws-resolver-rules-operator
• aws-rolling-node-operator
• aws-servicequotas-operator
• aws-tccpf-watchdog
• aws-vpc-operator
• azure-admission-controller
• azure-collector
• azuredisk-cri-driver-app
• capa-iam-operator
• cert-operator
• cluster-api-cleaner-cloud-director
• cluster-api-provider-aws
• cluster-api-provider-cloud-director
• cluster-apps-operator
• cluster-cleaner
• cluster-operator
• config-controller
• deletion-blocker-operator
• dex-operator
• dns-operator-aws
• dns-operator-route53
• encryption-provider-operator
• etcd-backup-operator
• etcd-kubernetes-resources-count-exporter
• event-exporter-app
• flux-app
• grafana
• hello-world-app
• irsa-operator
• kube-state-metrics
• loki
• macropower-analytics-panel-server
• management-cluster-admission
• node-operator
• oauth2-proxy
• organization-operator
• prometheus-meta-operator
• promxy-app
• rbac-operator
• release-operator
• silence-operator
• upgrade-schedule-operator
• vault-exporter
• vertical-pod-autoscaler-app

[Strigix]

For the repositories listed below, issues describing the wanted changes will be made.
This so that the changes and testing can be done by the teams themselves. (Lesson learned).

• azuredisk-cri-driver-app
• cluster-api-provider-aws
• cluster-api-provider-cloud-director
• flux-app
• grafana
• hello-world-app
• kube-state-metrics
• macropower-analytics-panel-server
• management-cluster-admission
• oauth2-proxy
• prometheus-meta-operator

[stone-z]

Opened PRs for azure-collector, cert-operator, cluster-cleaner, and aws-tccpf-watchdog.

Looks like giantswarm/vertical-pod-autoscaler-app#151 is ok - is there a blocker there?

[stone-z]

The CI failure in giantswarm/azure-admission-controller#422 does not seem like it could be related to your changes

[Strigix]

For giantswarm/vertical-pod-autoscaler-app#151
I still have to look where to apply everything.

Other leftover PRs are:

• cluster-cleaner (is being reviewed)
• Azure-collector (will be reviewed)
• Azure-admission-controller (some new vulns, and needs review)
• aws-tccpf-watchdog (will be reviewed)

Other than that.. Tickets are open, and we should be good to go.

[Strigix]

Team Shield's part of this ticket is done.
All PR's are either closed and merged, or tickets have been opened for the respective teams for the particularly difficult repos.