Story (Required)

As a consumer of road-core as upstream, we want to know how to configure road-core to verify or by-pass the rhdh authentication

Background (Required)

In RHDH lightspeed, the plugin uses RHDH authentication & RBAC: https://backstage.io/docs/auth/#identity-for-plugin-developers

however, with road-core running as a sidecar container in RHDH pod, there is a security concern that any user can shell into RHDH container; so that malicious user may shell into rhdh container and call road-core endpoint via cmd line. This will allow malicious users access other user's information.

this issue is to investigate a way to resolve this concern, block API access via RHDH container through cmd line. 

it can be either

1. block  API call in rhdh container cmd
2. investigate adding rhdh authentication to road-core auth configuration to verify the authentication: https://github.com/road-core/service/blob/main/ols/src/auth/auth.py
3. or any other way.

ideally, we want to avoid doing #2. rhdh fetchAPI have already done the auth & rbac verification, we don't want to duplicate the work. and what information is required to verify the authentication in RHDH?

i.e. API URL and token. if the API URL is required, typically it depends on the RHDH endpoints, which means the cluster host is required. may also want to investigate how to dynamically detect and add the auth config as part of https://issues.redhat.com/browse/DEVAI-258

in addition, RHDH use bearer token for auth. and the token changes and expires. not something can be statically set in rcsconfig: https://github.com/road-core/service/blob/3ea924f4945c0677e3ba8576161b37fb14b15075/examples/rcsconfig.yaml#L88-L92.
also the RHDH token may contain the logined user information, but cannot verify outside of RHDH, since it will need the RHDH catalog to get user entity and permission policy etc.

Out of scope

<Defines what is not included in this story>

Approach (Required)

<Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

Dependencies

<Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

Acceptance Criteria (Required)

<Describe edge cases to consider when implementing the story and defining tests>

<Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

documentation updates (design docs, release notes etc)
demo needed
SOP required
education module update (Filled by DEVAI team only)
R&D label required (Filled by DEVAI team only)

Done Checklist

Code is completed, reviewed, documented and checked in
Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
Continuous Delivery pipeline(s) is able to proceed with new code included
Customer facing documentation, API docs, design docs etc. are produced/updated, reviewed and published
Acceptance criteria are met
If the Grafana dashboard is updated, ensure the corresponding SOP is updated as well