search

giantswarm / roadmap

Giant Swarm Product Roadmap
https://github.com/orgs/giantswarm/projects/273
Apache License 2.0
3 stars 0 forks source link

Add Seccomp default profile to managed apps and core components #259

Closed pipo02mix closed 1 year ago

pipo02mix commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 notifications@github.com 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 https://github.com/giantswarm/roadmap/issues/259#issuecomment-770888387, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGZZ7KTWKERUGEFIX5C6ATS42ZUDANCNFSM4WZDVXLA .

--

Fernando Ripoll

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

nprokopic commented 3 years ago

There are some changes here in the upstream.

https://github.com/kubernetes/enhancements/issues/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 commented 1 year ago

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

stone-z commented 1 year ago

@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 commented 1 year ago

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:

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

List:

Strigix commented 1 year ago

Gonna have to revisit the ones done so far because I assumed some security context settings were referenced/standardized, which they weren't.

Strigix commented 1 year ago

There are issues with certain core components that have no volumes allowed in their own PSPs that SOMEHOW after this change refuse to get running pods. The error message will blame the annotation for the seccompprofile. Changes will be made to the PSPs of the affected components in which they'll be allowed to use either the volumetypes they use (information provided by a script of @fhielpos, thanks <3) or the same volumes that are already allowed in the restricted psp.

I will be revisiting:

Apologies for any inconveniences.

Strigix commented 1 year ago

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).

stone-z commented 1 year ago

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

Looks like https://github.com/giantswarm/vertical-pod-autoscaler-app/pull/151 is ok - is there a blocker there?

stone-z commented 1 year ago

The CI failure in https://github.com/giantswarm/azure-admission-controller/pull/422 does not seem like it could be related to your changes

Strigix commented 1 year ago

For https://github.com/giantswarm/vertical-pod-autoscaler-app/pull/151 I still have to look where to apply everything.

Other leftover PRs are:

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

Strigix commented 1 year ago

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.