Signature bundling and end2end tamper proofing the config elements of Kubescape

[entlein]

Overview

If signatures are switched on, we implicitely guarantee that not only can a profile no longer be manipulated but neither those elements, processes and files, that modify the (meaning of) a profile.

Furthermore, elements that are signed (hereafter fragments), must retain their valid signature if they are overlayed (think leaf) with other parts of signed elements of the same type, pertaining to the same object.

Problem

Detection is only guaranteed as long as the detection instrumentation (of which kubescape is part) can be considered intact. I m looking at a pure integrity problem here.
I ll assume that the signatures themselves are handled by vendors, users etc correctly and all private keys are not on the cluster.

Solution

Proposal 1:

a) We assume, kubescape ships with a certain default of rules, configs etc, those are signed as base
b) the vendors now ship (at least one) bundle for their thingy :
thingy can be:
- an external network endpoint
- a static manifest containing one app with at least one container ( jobs are difficult to sign, see the OLM problem -> deferred to later)
- a chart containing multiple apps or even sub-charts with multiple containers, grouped by bundle, these may be in same or different namespaces. The choice of namespace is with the user and is not part of the base signature.

since profiles and rules are coupled, they can be bundled together. Omission of any, does not invalidate others.

cli-util for vendors/users/everyone that flattens a (however formattted yaml) into the correct storage internal format (machine readable) and that can sign it (.e.g like so https://github.com/k8sstormcenter/bob/pull/197/changes#diff-48519eddc2c608f4a261424b515caba2a9839130e1080298baa07f91980e6090R22 )

• node-agent configfile (exposed in kubescape/values.yaml) to have a flag signature that will expect signed objects and public keys to be provided
  *** fully airgapped tamper proofing out-of-scope. Either Fulcio with OIDC or mount pub-key(s)***

• a signed trust-policy.json that identifies which keys to use to verify which objects.

• cps to carry additional labels:

1. a base CP: (provided by vendor)

apiVersion: spdx.softwarecomposition.kubescape.io/v1beta1
kind: ContainerProfile
metadata:
  name: redis-base
  labels:
    signature.kubescape.io/bundle: redis
    signature.kubescape.io/fragment-class: base
  annotations:
    kubescape.io/managed-by: User

2. an overlay CP (provided by user)

apiVersion: spdx.softwarecomposition.kubescape.io/v1beta1
kind: ContainerProfile
metadata:
  name: redis-ops-overlay
  namespace: redis
  labels:
    signature.kubescape.io/bundle: redis
    signature.kubescape.io/fragment-class: overlay
  annotations:
    kubescape.io/managed-by: User
spec:
  execs:
    - path: /usr/bin/df
      args:
        - /usr/bin/df
        - -h

Open questions: how to deal with inconsistent resulting logic -> Constanzes solution: Garbage in, garbage out. Kubescape cannot decide if the logic is useless.

Same for other objects , such a rules.yaml (as overlay of default-rules.yaml) ... still iterating on least friction

• rules

apiVersion: kubescape.io/v1
kind: Rules
metadata:
  name: rules-redis
  labels:
    signature.kubescape.io/bundle: redis
    signature.kubescape.io/fragment-class: overlay
spec:
  rules:
    - id: R0001
      name: Unexpected process launched
      some mod of original rule goes here

• various configs
  Configs should be goverend entirely by the user. I dont see how a vendor would modify that.

• some CRDs, such as collapsconfig
  Most CRDs are also purely kubescape owned, so a base signature should suffice.
  CollapsConfig is the only one that I see should be overlay.

Alternatives

Previous designs were different and vulnerable.

Additional context

• Component Tests that tries various methods of tampering individual files, (assuming a compromised cluster) must all be leading to an alert (unless kubescape is uninstalled from the cluster by the adversary in which case... well).

• Benchmark test where all objects are signed to estimate resource consumption delta

• Quick alignement with Matthias resulted in: we mount the pub keys and leave fully air-gapped problems to enterprise subscribers , also accept that if adversary has cluster-admin thats game over anyways.

This is WIP until I have all objects designed in a way I can imagine a vendor actually publishing them

[entlein]

https://github.com/k8sstormcenter/node-agent/pull/63/changes for early review of the direction please, if you get the chance (keys still hardcompiled herein and it needs a lot of cleaning, so probably the last link with the redis demo is the most illustrative and fastest to read through)

demo available here:
https://labs.iximiuz.com/courses/bobshort-6301b2ea/3signandverify/blue
and the text form and manifests easiest to read here:
https://github.com/k8sstormcenter/bob/pull/197/changes#diff-98ac3e0f05f516e482c53c1d9d9ed8cb44de2c5052c36ea0f34b323e3d567f70