Platform software control module (shturval-backend)

About the service #

The service is included in the Helm chart shturval-backend. This chart also expands the permissions negotiation operator (stp-controller), which produces a bundle for OPA. The authentication and session components are in chart shturval-auth.

Contents #

1. Review
2. Architecture
3. Installation/deployment
4. Diagnostics
5. Lifecycle
6. Service parameters

1. Review #

Purpose: main software interface for platform management via HTTP API (/api/v1): clusters, groups of nodes and providers (CAP family*), namespace/workload object resources if necessary, terminals and logs, metrics, integration with the authorization loop and external configuration points. The cluster state changes at the request of the operator/API client, and not through CR approval by its own reconcilers within the process.

Features #

Initiation scriptsai #

Limitations and implications #

Place in the chain of command #

The consumer sends an HTTPS request to the pod backend: the traffic is first processed by Envoy, which proxies it to the local process sh-backend-api on 127.0.0.1:8080. In parallel, the OPA sidecar checks authorization policies against the bundle of rights. The API process itself accesses the Kubernetes API to read and modify objects and to external URLs of partner components: authn-server, session-manager, ldap-cache, etc.

Related Components #

Key Features #

2. Architecture #

Workload Components #

The RBAC of a process in a cluster is determined by the manifests chart shturval-backend; The list of rights is not exactly duplicated here.

3. Installation / deployment #

Deployment is set by Helm chart shturval-backend. The API, Envoy, OPA, Swagger UI, permissions operator components and related objects (RBAC, Service, Ingress/Envoy configuration) are created in a single release.

Note: Any changes to installation parameters must be made in concert with the platform via ShturvalServicePatch (SSP) (or an equivalent approved mechanism), without manual changes outside of platform control.

4. Diagnostics #

Typical checks are as follows (NAMESPACE, DEPLOYMENT, POD substitute according to the actual installation; the Deployment name corresponds to the Helm chart values shturval-backend):

kubectl get deployment -n "${NAMESPACE}"
kubectl get pods -n "${NAMESPACE}" -o wide
kubectl describe pod -n "${NAMESPACE}" "${POD}"
kubectl logs -n "${NAMESPACE}" "${POD}" -c sh-backend-api --tail=200
kubectl logs -n "${NAMESPACE}" "${POD}" -c envoy --tail=200
kubectl logs -n "${NAMESPACE}" "${POD}" -c opa --tail=200

5. Life cycle #

Processing path one externalHTTP request types are as follows:

The section does not contain reconcile, finalizers, or controller-runtime queues for the API process itself.

6. Service parameters #

The configuration is set by the environment variables of the process. Variables important for the platform link:

Where to configure #

Services and repositories → Installed services → shturval-backend → Manage. The service runs in the management cluster.