spiffe / tornjak

Tornjak is a UI and management layer used for brokering human access to one or more SPIRE deployments

Tornjak

The project aims to provide a management plane and capabilities for SPIFFE identities managed by SPIRE. The goals are to provide global visibility, auditability, and configuration and policy management for identities. This can be thought about as a central management plane for identities across SPIRE servers, with the aim for use by an administrator or CISO to govern an organization's workload identities.

About Us

• Tornjak Slack channel on CNCF SPIFFE
• Tornjak Blogs
• YouTube Tornjak channel

Get Started

The following are guides on how to try out Tornjak:

• Tornjak simple deployment with SPIRE k8s quickstart

A list of releases can be found at https://github.com/spiffe/tornjak/releases. These releases include source code for each stable version of Tornjak image tags. The tag tornjak-X.Y.Z corresponds to official pre-built released image. For example, for tornjak-backend, the pre-built image corresponding to the code at release tornjak-X.Y.Z is tornjak-backend:vX.Y.Z.

Here are a few additional resources:

• Tornjak basic functions demo

In case of deployment or configuration troubles, check out our hints documenation

Architecture and roadmap

The architecture consists of 2 main components, the agent and the manager.

• The manager provides a management control plane for SPIRE servers, and a central point of data collection. It interacts with the agents, SPIRE servers, and corresponding components to achieve this.
• The agent provides a way for the management plane to communicate with the SPIRE servers and provide introspection and configuration of identities.

For more details of the components and execution plan, please refer to these documents

• Manager design and details
• Agent design and details
• Execution plan

Development: Building and pushing

To request features or report bugs, please use Github Issues. To get started on development, please see CONTRIBUTING

tornjak's Issues

Do a sweep through and Remove "any" Type

• Creating an issue in case this gets lost.
• Have TODO(mamy-CS) tag

[Documentation] add cluster api doc

Our api's are listed here.

We have not updated this with the cluster create/edit/delete api's.

Might also be worth making a separate usage doc with just the api's, and a separate doc for some of the architecture?

Tornjak Integration with IAM - User Management and Authorization

We would like to collect suggestions and feedback on integrating User management tools/ hooks with Tornjak. Below are some of the tools that we researched. If there are other or better options, we would like to hear from you. If possible with the pros and cons.

Here is what we would like to accomplish.

We would like for Tornjak to have a Role authentication pipeline that ensures:

• Viewer - Not to make changes or access exclusive information
• Admins - Be granted administrative privileges and access information accordingly

Break Down for Tornjak

A viewer/ Non-Admin Users - Cannot make changes or access exclusive information
ALLOWED:

• View Clusters page
• View the Agents tab
• View the Entries tab
• View Tornjak ServerInfo tab
• View the Tornjak Dashboard tab
• Download entries to YAML

NOT ALLOWED

• No Cluster Management page
  • No cluster creation
  • No cluster editing
• No Create Token Page
• No Create Entries Page
• No banning
• No deleting

An Admin - Full Access with administrative privileges

• Create and manage Clusters
• Create and manage Entries
• Manage Agents

Some User Management Tools

1. LoginRadius (loginradius.com/open-source)- Customer Identity and Access Management (CIAM) Platform

• React SDK for implemented LoginRadius for react applications
• 5000 users on free version
• 1 web app integration on free version

2. Auth0 (auth0.com/opensource)- application redirects users to an Auth0 customizable login page when they need to log in. Once your users log in successfully, Auth0 redirects them back to the app, returning JSON Web Tokens (JWTs) with their authentication and user information.

• 7,000 free active users and unlimited logins.
• Auth0 universal login for web, ios, and android
• unlimited serverless rules to customize and extend Auth0's capabilities

3. FusionAuth (fusionauth.io) - Fast, secure authentication and identity management that is flexible, easy to deploy, and ready to scale from 1 to 100 million users.

• Free version has full API access, custom user data, JWTs, refresh Tokens, configurable CORS, login, registration, email verification, forgot password, account locking, long-lived sessions, 3rd party login, password hashing, webhooks, user management UI, unlimited users
  Others: OKTA, REACHFIV, SENTRY LOGIN, SPHERE IDENTITY,
  Open Identity, Keycloak, OpenIAM, FusionIAM...

Fully Open Source Single Sign On Identity Management Tools

1. KeyCloak
   • Based on OpenID Connect, OAuth2.0, and SAML2.0.
   • provides SSO capabilities across web applications
   • Provides integration with LDAP and Active Directory
   • can manage roles, permissions, and sessions
   • Provides client libraries for many languages such as Java, JavaScript, and C#
   • Written in java
   • Provides Client Adapters
   • User-Friendly UI
   • Authentication as Service
2. IdentityServer
   • open source free single sign-on software. It is a cross-platform framework based on OpenID Connect and OAuth 2. 
   • central authentication and authorization capabilities
   • It supports federated identities, multiple flows, and API authorization
   • Self hosting
   • Written in c#
   • Claim-based Provider
   • Cross-Platform
   • UI Customization
   • Access Control for API
   • Single Sign-on /Sign-out
3. CAS (Central Authentication Service)
   • built on client-server architecture
   • Supports many protocols such as OpenID, OAuth, OpenID Connect, REST, WsFederation, and SAML
   • comprehensive system for integration with third-party apps
   • Written in java
   • UI To Manage Monitoring And Stats
   • Password Management
   • Multilingual
   • Multi-factor authentication
4. Authelia
   • support for LDAP and Active Directory
   • intuitive user interface that lets users navigate easily
   • two-factor authentication based on Google Authenticator OTP with Yubikey
   • works with a reverse proxy such as Nginx
5. WSO2
   • supports almost all popular identity standards to provide authentication
   • has exposed API end pints for the integration with other applications
   • user-friendly interface that is highly customizable.
   • offers two-factor authentication
   • mainly written in Java
   • Cloud integration
   • Flexible
   • Identity provider

API endpoint to mind certificates ?

Is there any API end point to mint certificates (instead of cli ./bin/spire-server mint x509...)?

Error when Entry List empty

When Tornajk is started with initialized SPIRE that has no agents and no Entries, the Entry List panel shows error:

Entries List
Request failed with status code 400

And the spire-server-0 log loops:

time="2021-09-23T18:40:18Z" level=debug msg="Notifier handled event" event="bundle loaded" notifier=k8sbundle subsystem_name=ca_manager
Endpoint Hit: Agent List
Endpoint Hit: Server Info
Endpoint Hit: Selector List
Endpoint Hit: Entry List
Endpoint Hit: Entry List
Endpoint Hit: Entry List
Endpoint Hit: Entry List
Endpoint Hit: Entry List
Endpoint Hit: Entry List
Endpoint Hit: Entry List
Endpoint Hit: Entry List
Endpoint Hit: Entry List
....

[arch] Integrate Typing into React JS frontend

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/82

Typing good. we want typing.

Untyped JS abstractions become an overhead to manage as the project grows because of lack of typing. Some typing system should be explored or perhaps a pivot to something like angular.

Tornjak Dashboard shows some agents with `OK` status.

We should change the status to something else to indicate that attestation has failed.

[backend/pkg] refactor backend pkg tests constants

declare constants in the beginning of the tests instead of calling them throughout the tests

[Feature: auth] [manager] Implement IAM for Tornjak Manager

We have focused IAM feature implementations on only the configuration of Tornjak that focuses on one Tornjak backend and SPIRE server. This will allow secure management of access across multiple SPIRE servers or trust domains.

Define inherited types and props more clearly

A better way to define inherited types and props

[backend/agent] Change method of obtaining cluster AgentsList from backend agent db

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/71

The way agents are parsed in the DB processor is via splitting on , via a concat query in the database:

Line of code below [uses strings.split(",")]
https://github.com/lumjjb/tornjak/blob/6c126e316a157548ca9835773feb522c56bf5f6b/tornjak-backend/pkg/agent/db/sqlite.go#L209

This probably can be handled better, in case spiffeids for some reason include ,s, which shouldn't be the case at least.

Implement Pagination support for entry list

More recent versions of SPIRE (1.3.2) have implemented pagination support for entry show command. Tornjak backend should be able to interact with this, and should also at some point implement pagination for sending information to the frontend.

Update documentation about deprecating images with Tornjak and SPIRE packaged together.

Since the PR #97 Tornjak can no longer be packed along the SPIRE container in a single image. SPIRE is using scratch and Tornjak requires alpine (to use shell). We separated the Tornjak code into a separate container that might be co-running with SPIRE in a single pod. All the documentation is still referencing the old image with SPIRE and Tornjak together. Update the documentation with references to the new deployment model

Investigate Liveness and Readiness Probe Parameters in deployment

When deploying Tornjak as a sidecar, we would like to define recommended Liveness and Readiness probes

Tornjak Feedback Thread - What do you want to see?

This is an issue to collect feedback on what folks would like to see with the project. It will be helpful to provide as much information as possible! Here are a few guide questions to help provide more directed/actionable feedback!

What kind of features would you like to see with the Tornjak project?
What type of use cases would you like to use Tornjak for?
What type of user would this be for?

Securing Tornjak with Keycloak

• We are looking for feedback on how we will integrate Keycloak as a user management tool with Tornjak.

Referencing - #61

Specific plan details for Tornjak React Front-End and GO Back-End

• One Client configured in Keycloak - Frontend communicates with public client under the Tornjak realm
• Frontend client has public access since it just needs to log in and redirect to a valid URI after successful login (Turn off client Authentication under clients settings - When it's ON, the OIDC type is set to confidential access type. When it's OFF, it is set to public access type)
• Backend receives a bearer-only token included in the request and it never initiates login on its own.
• Realm roles and client roles assigned and mapped for tornjak public client
• Roles embedded with the JWT Token through Keycloak configuration, now we can get the client roles from the JWT token with the “roles” key.
• Initially user sees the Keycloak login page
• User tries to log in to the front-end react application
• User will be redirected to the Keycloak server for authentication.
• If authentication is successful, Authenticated user will be redirected to the Tornjak application. At the same time, the user will get a JWT (JSON Web Token).
• Send the token as a header to the back-end with the request
• Unauthenticated users will be redirected back to the Keycloak login page.
• With the valid token, the front-end can access the back-end GO rest API by sending the token along with the service request.
• At every request sent, the request will be intercepted to check token validity. If expired, the token will be refreshed by communicating with keycloak and the updated token will be sent to the backend with the request.
• Back-end will validate the token with a public key from keycloak
• Back-end will check specified role for the user
• Back-end will make APIs accessible based upon the specific roles (Admin or Viewer)
• If the token is valid, the back-end will serve the request accordingly.
• If the token is invalid, the back-end will respond with error code 401 (Unauthorized) or 403 (forbidden) for a specific role.
• Logout - redirected back to key cloak login page

Hide Dashboard Piechart Legends in a modal

MOVED FROM ORIGINAL REPO lumjjb/tornjak-old#101

• Currently when the number of components increases significantly the size of the piechart becomes smaller.

Solution: Keep legends hidden in a modal and keep the piechart's size consistent.

[Feature] Dashboard for organizational identity view

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/40

Feature: Dashboard for organizational identity view
Box Note:
https://ibm.box.com/s/uu9hvimaokhbiz6qd253ow4vad7tdw59
Flows:
Stories to work on Epic 
1 - Cluster Management Page

• Cluster Create Page, Cluster Edit Page, Cluster List Page

• BackEnd - https://github.com/lumjjb/tornjak/issues/64
• FrontEnd [UI] - https://github.com/lumjjb/tornjak/issues/65
  • Part 1: Dashboard
  • Part 2: View details entry page
    2 - Design of DashBoard UI and data model [Overview page]
    3-  Details of Cluster/ Agents/ Entries Page 

Overview

This feature consists of the goal of allowing better oversight of workload identity. This consists of:

• Ability to view workload identities based on organizational constructs (clusters, nodes, workloads, etc.) instead of having to map internally to agents/entries, etc.
• Ability to automatically identify these constructs, or provide ability for user to annotate and define these constructs around SPIRE concepts
• Ability to navigate through the constructs (e.g. clicking on a node shows all identities registered to the node/agent) and obtain information and perform actions (i.e. logs of SVID provisioning and attestations)

Consideration of moving propagation of logging information to a separate feature since the scope is rather large.... Or start with a rather naive propagation of metrics exposed by a simple tornjak API.

Motivation

• Create a lower barrier of entry of utilizing SPIFFE/SPIRE for operators, CISOs, etc. who are interested in workload identity, but not familiar with underlying SPIRE mechanics.
• Propagate identity use information (e.g. minting of identities, attestation actions, etc.) to the control plane for monitoring and auditing.
• Provide a way to organize workload identity and agents in a way that matches the organization structure

Tasks

• Ability to derive some structure based on the definition of identity (i.e. trust domains, agents, and entries parent IDs)
• Ability for user to define metadata and tags around SPIRE servers, agents and entries to be used to provide structure
• Dashboard
  • Define structure to be able to organize identity
  • Define the exploration dashboard overview
    • Within each trust domain: Clusters, nodes, workloads
    • On the organization level (MANAGER-ONLY): Groups
  • For each view, provide information related, including selectors, and general statistics
  • Organizational View data table
    • As an extension to dashboard, provide showing workload identity in table similar to entries/agents
    • Provide ability to filter and search based on tags and metadata
  • Add metadata search for entry/agent list
• Information propagating:
  • As part of the dashboard view, additional data should be used to provide useful views and statistics, this can include:
    • Information from SPIRE server Debug API (https://github.com/spiffe/spire-api-sdk/blob/main/proto/spire/api/server/debug/v1/debug.proto)
    • Identity provisioning from SPIRE server logs (NOTE: Perhaps can be another feature on its own since its scope is rather big), alternatively fairly simple analysis can be done locally on each tornjak agent and only basic statistics propagated via tornjak API.
      • Define scalable way to keep logs up to date as well as provide filters to populate data structures. This should be done on the agent level, and propagated up to the managers.
        • maybe something like prometheus would work here for just metrics
        • or for log aggrergation and analysis, we could use Elasticsearch or Grafana/loki

Unless specified explicitly, functionality should be capable on agent views as well as managers.

Dashboard ideas

Something similar to k8s, where there is graphical information on top, and then a list of higher level constructs i.e. deployments <--> nodes/agents and pods <--> workloads

[frontend] #entries in ClustersTable dashboard is incorrect

In the cluster table in the dashboard, the number of entries per cluster is inaccurate. This is due to the cluster #entries field not being updated with the function that counts entries associated with each agents' entries (refer to lumjjb/tornjak-old#84).

This needs to be updated to use a function like getAgentsEntries.

[enhancement] Reduce the amount of action imports for each Tornjak Web component

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/48

There are multiple imports from actions, this probably can be abstracted since it is only used for initialization of state.

import {
  serverSelectedFunc,
  agentsListUpdateFunc,
  tornjakServerInfoUpdateFunc,
  serverInfoUpdateFunc,
  selectorInfoFunc,
  tornjakMessegeFunc
} from 'actions';

Relevant files: components/*.component.js,
and call usage by components/tornjak-api-helpers.js

[Feature] Add "Delete" button in Cluster Management view

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/92

It would be nice to have an additional Delete button on "Clusters" --> "Cluster Management" view. When the cluster is selected, the button allows deleting it. This function requires confirmation, to avoid accidental removal.

Refactor Is_manager logic

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/25

Currently IsManager logic is intertwined into the main logic of most components, however, each of the individual components don't necessarily need to know if it is in manager mode or not if the dataset presented to it is filtered.

This is issue is around moving the use of IsManager to a abstraction where most of the UI components don't need to know whether it is running as a manager. For example, agent list doesn't need to know if its a manager, it just needs to be given the right dataset.

Replace window.alert with react-toastify library.

Implement toast notifications as a replacement for standard browser alert.
https://www.npmjs.com/package/react-toastify
Or standard carbon component https://www.carbondesignsystem.com/components/notification/usage/.

Integrate i18n library for future language support of the frontend app (react-i18next).

https://www.npmjs.com/package/react-i18next

[Feature:auth] Implement PKCE for more secure Authorization feature

With the current Auth settings, it is vulnerable to Cross-Site Request Forgery and Replay Attacks because it is possible to intercept an authorization code and retrieve access tokens.

To fix this PKCE is the recommended augmentation to the standard authorization code flow to ensure the entity requesting the access token is the same as that which requested the authorization code.

Make other Tornjak backend arguments configurable

Currently the container only accepts three arguments (config paths and expandEnv flag)

It should also allow other values such as tls or mtls to be configured on runtime.

[Feature] Workload Entry Expiry Time UI Handling

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/80

Add additional ways to define expiry time in the creation of an entry and add clearer visual indication of when something is expired in the dashboard.

• [entry/create] provide warning about creating entry that has already expired (Perhaps some red exclamation)
• [entry/create] (Maybe?) Add other options for expiry time entry? Like absolute date/time
• [dashboard] Add clearer indication in dashboard entry table for expired entries (color coding rows maybe)

Tornjak Manager Errors for Invalid TLS Cert.

When the Manager configured with invalid TLS Certificate, we see the following errors:

• Agents List:
  http://localhost:50000/agents
  Error retrieving space-x05 TLS : Request failed with status code 400

• Server Info:
  http://localhost:50000/tornjak/serverinfo
  (empty page)

• Entries List:
  http://localhost:50000/entries

Error retrieving space-x05 TLS : Error: Request failed with status code 400:Error making api call to server: Post "https://tornjak-tls-tornjak.space-x05-0000.us-east.containers.appdomain.cloud/api/entry/list": x509: certificate is valid for *.space-x-01--0000.us-south.containers.appdomain.cloud, example.com, www.example.com, not tornjak-tls-tornjak.space-x05-0000.us-east.containers.appdomain.cloud

[Feature: auth] update backend to authenticate with multiple JWKS

currently, backend can only authenticate with one JWKS. However, if there are multiple clients that need to access (say, human users and also another machine or process), the backend does not currently support.

[tornjak-manager] Add ability to delete server

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/24

Request for feature: Add ability to delete server in server management in the tornjak manager

[Documentation] clean up tutorial code and consolidate all instructions

• consolidate all uses of tornjak agent vs tornjak backend terms
• create versioning system for all images
• remove the dev instructions from the front page - maybe make separate docs for development
• quickstart files need renaming and maybe one central file to point to the rest
• README: add index + simple architecture diagram (suggestion by @mamy-CS)
• Tornjak quickstart file indexing (suggestion by @mamy-CS)

[edited to consolidate comments]

Replace window.confirm with Carbon alternative.

https://www.carbondesignsystem.com/components/modal/usage/
Carbon modal offers an alternative to window.confirm.

update quickstart

need to include

• new image name
• config file maybe?
• split frontend and backend

Evaluate usage of CSI driver instead of hostPath and socket

Due to security concerns several SPIRE deployments prevent opening hostPath on the host machine. Evaluate using CSI driver for Tornjak to communicate with the SPIRE. See details here: https://github.com/spiffe/spiffe-csi

[frontend] Dashboard Tables Multi-Filter with data Grid

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/93

Currently, dashboard tables allow the application of only 1 filter at a time.
i.e. filter by "parentId contains ..."

One should be allowed to apply multiple filters at a time.
i.e. filter by "parentId contains ... AND has admin flag"

[Feature: auth] Implement auth option to revoke access

The current authorization code flow uses access tokens as session tokens. However, when a user logs out, the access token will still be registered as valid. This is because the backend validates a token only by checking the following:

• JWT signature against the public keys of the auth server
• the expiry
• the correct roles.

There are no explicit calls to or from the auth server with the backend.

To introduce revocation as an option, this will involve introducing more communication between the auth server and the backend.

Refactor jsx expressions/ component for table data

Table data such as agentList need to be refactored to use pure array.

[Tornjak-agent] Allow flag for CA cert for mTLS validation

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/12

RIght now, the same cert is used for mTLS that is provided for TLS, this should be configurable to use the Root CA.

   --cert value         CA Cert path for TLS/mTLS
   --key value          Key path for TLS/mTLS
   --tls                Enable TLS for http server (default: false)
   --mtls               Enable mTLS for http server (overwrites tls flag) (default: false)

By adding a --ca flag to it.

Allow use of expandEnv flag for spire configuration

We are using the expandEnv flag when running the Spire server in order to expand environment variables in the configuration file. Right now the expandEnv flag is being hardcoded as false within tornjak. We would like to be able to use this flag when running tornjak.

Require Audience check in Tornjak backend

This is to help support IAM clients that may call several Tornjak backends (resource servers) connected to the same IAM - especially for the Tornjak Manager

[cleanup] Refactor Tables for code reuse, readability and cleanup

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/70

Some UI components are reusable but copy-pasted, these should be addressed throughout the code

Currently - Multiple tables with same code.
To-Do - Code reuse, one table class, and reuse for all tables.
Breakdown in classes for readability [Investigate further for best implementation]

Reference discussion: https://github.com/lumjjb/tornjak/pull/66#discussion_r665607810

[Tornjak-frontend] Clean up error handling

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/69

Cleanup Error Handling in a more methodical way for Tornjak. Return, handle and propagate errors instead of returning silently in some cases.
We basically need to improve the error handling. Sometime we just get back the empty page with no errors, no details.

• We need to make sure we always communicate the errors back to the user.
• We need to have a better error logging functions, with various levels (DEBUG, INFO, ERROR)
• Eventually, have a single error handling component to manage all the errors and exceptions in a single place
• Design with ability to provide the error catalog in the future, so they can be translated (if there is a need for it)

Review our CORS Cross-Origin Resource Sharing

Review our Cross-Origin Resource Sharing CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
and Cross-Origin Resource Policy CORP https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)

https://github.com/spiffe/tornjak/blob/main/tornjak-backend/api/agent/server.go#L683
https://github.com/spiffe/tornjak/blob/main/tornjak-backend/api/agent/server.go#L339-L346

Read up on CSRF https://en.wikipedia.org/wiki/Cross-site_request_forgery

[frontend] Modify frontend auth logic to refer to backend for auth server location

Currently, the frontend knows to run auth logic and redirects because of input values and configs
It would be useful if the frontend could run without the need for configuration, based on a call from the backend

Upgrade project dep. "react-scripts" to version 5 and fix dependencies crashes.

This task will allow the project libraries to be up to date and not need legacy dependencies to be used when developing/debugging or testing the project on local.

[Feature] Allow multi entry create: Create on multiple agents

MOVED FROM ORIGINAL REPO https://github.com/lumjjb/tornjak/issues/39

When creating an entry allow creation of same entry on multiple agents.

[Feature: auth] Decouple the authorization logic from the backend application in Auth feature

Currently, the authorization logic is application-implemented. This means if a user wants to change the access policy, they would need to code it and build a custom image.

Clearly, it would be better to have the logic defined outside the application, and can open the way to other types of access control like ABAC. Some solutions may include:

• Introducing a configmap that gets passed in - this is probably the simplest solution to implement, though offers less flexibility, and is more prone to implementation mistakes. Requires more thought on how we can define policies.
• Introducing a policy engine integration - this offers the most flexibility, but may be more involved to implement, and potentially puts more burden on users to set up the policy engine.

Error when running with SPIRE image version '1.3.5'

The error log:

time="2022-11-11T22:47:23Z" level=info msg="Opening SQL database" db_type=sqlite3 subsystem_name=sql
time="2022-11-11T22:47:23Z" level=info msg="Running migrations..." schema=17 subsystem_name=sql version_info=1.1.5
time="2022-11-11T22:47:23Z" level=info msg="Migrating version" schema=17 subsystem_name=sql version_info=17
time="2022-11-11T22:47:23Z" level=error msg="Fatal run error" error="datastore-sql: migrating from schema version 17 requires a previous SPIRE release; please follow the upgrade strategy at doc/upgrading.md"
time="2022-11-11T22:47:23Z" level=error msg="Server crashed" error="datastore-sql: migrating from schema version 17 requires a previous SPIRE release; please follow the upgrade strategy at doc/upgrading.md"

[build] change the image tags to create Tornjak version system

we currently use "latest" for non-SPIRE including images, but should create a new version system

Quickstart issues

• need step to delete po after statefulset edit
• make backend browser image visible
• fix the frontend