compliance monitor: restructure table/table_full and permissions

[garloff]

The compliance monitor offers two similar views:

• https://compliance.sovereignit.cloud/page/table -- no HTTP auth, displays verified results, no access to reports
• https://compliance.sovereignit.cloud/page/table_full -- HTTP basic auth, displays all results (even unverified), access to reports

This is not well documented (see original bug report below) and less transparent than necessary. As decided in SIG Std/Cert:

• no auth should be required regardless of results are verified or not
• unverified results MUST be recognizable as such (with an admonition that they may contain false positives)
• reports should be made available without auth in a curated form (containing only those log lines that are explicitly linked to any testcase)
• the only gated view then would be the full report with the detailed logs

From my (mbuechse's) POV, this means:

1. make table view switchable between verified results and all results by including a corresponding link; I suppose we can use a simple query parameter for the table endpoint and replace table_full with an HTTP forward
2. as mentioned, make it very apparent at first glance what kind of results are displayed
3. include a link from the curated report to the full report, mentioning that the latter needs a login; this will most likely require introducing a new endpoint (because making auth optional doesn't work well with browsers)

---

original bug report:

Currently, the CNDS cloud fails volumes backups most of the time.
Without the volume backup test, it can still pass v4 of SCS-compatible IaaS, but not v5.1.
Currently, https://compliance.sovereignit.cloud/page/table shows CNDS as v5.1 compliant, where as https://compliance.sovereignit.cloud/page/table_full shows v4 and upon digging into the details, I can indeed see the volume backup test last night failed.

Questions/Remarks:

1. I would expect those two tables to come to the same conclusions. If that is not the case, some documentation that explains why not would be helpful. So, maybe I did not find the right documentation, or there is a documentation bug or a code bug.
2. We are hiding the logs from normal observers behind a long for the table_full. Do we really need to? Maybe better invest some extra care to ensure we can not possibly leak credentials, so we no longer need to hide logs? Or are there other valid reasons to hide them?

[mbuechse]

The public table will only show failures that have been manually approved, as long as the test has been passed in the last 7 days. We do this (it was a group consensus in the SIG Std/Cert) to avoid showing false positives to the public.

[mbuechse]

As for the logs, they contain important information for debugging, including many things that could easily be misread as problems on the CSP side. It may be possible with reasonable effort to strip credentials from the logs, but I'm not sure when it comes to other debugging info.