Suseobs store

[jvanz]

POC adding a new store to send the audit scanner results to suse observability.

Warning

It still have room for many improvements. See this PR as a knowledge sharing with the team. Not the final code to be merged. There are many comments with some point of improvements.

The logic of the requests to the SUSE Observability is:

1. Send a payload with the start_snapshot field to start the snapshot creation. It should not contains the stop_snapshot field
2. Send all the health check created by the audit scanner
3. Send a payload with the stop_snapshot field. It should not contains the start_snapshot field

See more information about the payload here

Example the payloads sent to create a health snapshot:

{
  "apiKey": "V1dLjMKA008I3h7HisT3BXh9rWlHaWk2",
  "collection_timestamp": 1741902901,
  "internalHostname": "stackstate.hpc9u27",
  "metrics": [],
  "service_checks": [],
  "health": [
    {
      "consistency_model": "REPEAT_SNAPSHOTS",
      "start_snapshot": {
        "repeat_interval_s": 300,
        "expiry_interval_s": 360
      },
      "stream": {
        "urn": "urn:health:kubewarden:audit_scanner",
        "sub_stream_id": "kubewarden1"
      },
      "check_states": []
    }
  ],
  "topologies": []
}

{
  "apiKey": "V1dLjMKA008I3h7HisT3BXh9rWlHaWk2",
  "collection_timestamp": 1741902902,
  "internalHostname": "stackstate.hpc9u27",
  "metrics": [],
  "service_checks": [],
  "health": [
    {
      "consistency_model": "REPEAT_SNAPSHOTS",
      "stream": {
        "urn": "urn:health:kubewarden:audit_scanner",
        "sub_stream_id": "kubewarden1"
      },
      "check_states": [
        {
          "checkStateId": "clusterwide-no-host-namespace-sharing-default-pod-privileged-pause-pod-clusterwide-no-host-namespace-sharing",
          "message": "",
          "health": "Clear",
          "topologyElementIdentifier": "urn:kubernetes:/kubewarden1:default:pod/privileged-pause-pod",
          "name": "clusterwide-no-host-namespace-sharing"
        },
        {
          "checkStateId": "clusterwide-drop-capabilities-default-pod-privileged-pause-pod-clusterwide-drop-capabilities",
          "message": "",
          "health": "Clear",
          "topologyElementIdentifier": "urn:kubernetes:/kubewarden1:default:pod/privileged-pause-pod",
          "name": "clusterwide-drop-capabilities"
        },
        {
          "checkStateId": "clusterwide-safe-labels-default-pod-privileged-pause-pod-clusterwide-safe-labels",
          "message": "",
          "health": "Clear",
          "topologyElementIdentifier": "urn:kubernetes:/kubewarden1:default:pod/privileged-pause-pod",
          "name": "clusterwide-safe-labels"
        },
        {
          "checkStateId": "clusterwide-no-privileged-pod-default-pod-privileged-pause-pod-clusterwide-no-privileged-pod",
          "message": "Privileged container is not allowed",
          "health": "Deviating",
          "topologyElementIdentifier": "urn:kubernetes:/kubewarden1:default:pod/privileged-pause-pod",
          "name": "clusterwide-no-privileged-pod"
        },
        {
          "checkStateId": "clusterwide-do-not-run-as-root-default-pod-privileged-pause-pod-clusterwide-do-not-run-as-root",
          "message": "",
          "health": "Clear",
          "topologyElementIdentifier": "urn:kubernetes:/kubewarden1:default:pod/privileged-pause-pod",
          "name": "clusterwide-do-not-run-as-root"
        },
        {
          "checkStateId": "clusterwide-no-privilege-escalation-default-pod-privileged-pause-pod-clusterwide-no-privilege-escalation",
          "message": "",
          "health": "Clear",
          "topologyElementIdentifier": "urn:kubernetes:/kubewarden1:default:pod/privileged-pause-pod",
          "name": "clusterwide-no-privilege-escalation"
        },
        {
          "checkStateId": "clusterwide-do-not-share-host-paths-default-pod-privileged-pause-pod-clusterwide-do-not-share-host-paths",
          "message": "",
          "health": "Clear",
          "topologyElementIdentifier": "urn:kubernetes:/kubewarden1:default:pod/privileged-pause-pod",
          "name": "clusterwide-do-not-share-host-paths"
        }
      ]
    }
  ],
  "topologies": []
}

{
  "apiKey": "V1dLjMKA008I3h7HisT3BXh9rWlHaWk2",
  "collection_timestamp": 1741902902,
  "internalHostname": "stackstate.hpc9u27",
  "metrics": [],
  "service_checks": [],
  "health": [
    {
      "consistency_model": "REPEAT_SNAPSHOTS",
      "stop_snapshot": {},
      "stream": {
        "urn": "urn:health:kubewarden:audit_scanner",
        "sub_stream_id": "kubewarden1"
      },
      "check_states": []
    }
  ],
  "topologies": []
}

[jvanz]

Yes, this is very ugly. And it needs to be refactored.

What do you think about having multiple stores? For example, the audit scanner could create policy reports and send the data to SUSE Obs.

[jvanz]

If we decide to allow multiple store types. I think we should move the store configuration to a file.

[jvanz]

In the consistency mode used to send the health checks to SUSE Observabiliry (REPEAT_SNAPSHOT), it necessary to send a payload to start the snapshot and another to close it. All the request between these two request, will be the health checks send by the audit scanner.

I've add these functions here just to avoid any the work to handle the concurrency nature of the audit scanner and the need to add some control to avoid multiple start/stop snapshot payloads. If we send more then one of this payload, the health checks will not work as expected.

[jvanz]

This is related to this comment

[jvanz]

Refactor this for something more meaningful. As the SUSE Obs is not actually storing the reports...