Remove SPIRE config file requirement

[maia-iyer]

Because we have split SPIRE from Tornjak container, potentially would be good to remove this requirement. Depends on #119

[mrsabath]

Currently, removing SPIRE config creates a following error:

kubectl -n tornjak logs spire-server-0 -c tornjak
-t /run/spire/tornjak-config/server.conf
/run/spire/tornjak-config/server.conf
-c SPIRE_CONFIG must be provided

[mrsabath]

The best solution would be to get the config directly from SPIRE via SPIRE APIs, but there are no such today.
SPIRE config is typically passed to SPIRE server container as a ConfigMap. When possible we should just be able to connect to this ConfigMap via VolumeMount on the backend container. We should remove the required file though, so when it's not available we just return an appropriate message, when access to config requested via Tornjak API.

[maia-iyer]

I agree with removing the requirement for the file, though the VolumeMount even doesn't quite return the correct ConfigMap because there's the option of the SPIRE executable parsing from container environment variables, which the Tornjak sidecar does not share.

The original goal of serverinfo was to provide easy test end-to-end from Tornjak backend to SPIRE server.

#161 is a new PR implementing two new APIs; healthcheck and debugserver, which both are easy tests of the end-to-end working. In particular, maybe debugserver returns nice amount of SPIRE server information. Example:

{
    "svid_chain": [
        {
            "id": {
                "trust_domain": "example.org",
                "path": "/spire/server"
            },
            "expires_at": 111,
            "subject": "O=SPIRE,C=US,2.5.4.45=#12321"
        },
        {
            "id": {
                "trust_domain": "example.org"
            },
            "expires_at": 222
            "subject": "O=SPIFFE,C=US"
        }
    ],
    "uptime": 333,
    "federated_bundles_count": 1
}

Perhaps we could replace serverinfo implementation with a single call to debugserver.

The main caveat is that in the frontend, the Tornjak ServerInfo tab relies on serverinfo command if I am not mistaken because it parses the config plugins (@mamy-CS please confirm?). I think what's there looks nice, but if we remove the requirement of passing the config file, what should be displayed in this ServerInfo tab?

[mrsabath]

I think that serverinfo API should return SPIRE Server Information. If the information is not available, e.g. no ConfigMap volume defined, this API call should return an appropriate info. I am OK with returning the content of the debugserver as a debugserver Tornjak API, but we should not change the content of the call. If we always guarantee to return some meaningful value for the debugserver call, we can switch to use this call as a default test for Frontend to validate SPIRE APIs. Same with the healthcheck call

[maia-iyer]

Offline conversation with @mamy-CS - we decided to stick with the serverinfo call as specifically not calling the spire-server and instead return information about SPIRE config if available (and if not, returning some kind of message about that). As debugServer and healthcheck are separate calls, we didn't want to make the APIs too confusing by adding redundant commands for this information