Opstella Integrations with Tools Testing

Opstella Single Sign-On Function

✅ All of the steps below, if all done sucessfully, it can be said that Opstella Single Sign-On functions properly with other components.

Every tile signs you out of the tool first

Each button on the SSO page opens https://<tool>.${BASE_DOMAIN}/clear-session?redirect_uri=<deep-link>, which clears the tool’s own session on purpose so the login always goes through the Opstella IdP and never reuses the previous user’s session.

So having to click the tool’s own ... with Opstella button every time is expected, not a broken SSO — even for a tool you were already signed in to a moment ago. The test passes when that button logs you in as your Opstella user, not when a tile lands you straight on the content page.

Go to Opstella Single Sign-On Page

1. Go to opstella.${BASE_DOMAIN} with Opstella Administrator Credentials

   

2. Go to Single Sign-On Page (SSO) ; Click SSO button on the left.

   

GitLab

GitLab installed as Omnibus on a VM answers `/clear-session` with 404

The opstella-clear-session Ingress carries a rule for gitlab.${BASE_DOMAIN}, but when GitLab is installed on its own VM (as GitLab describes) that hostname resolves to the VM, not to the cluster Ingress — so the rule never receives traffic and the tile shows GitLab’s own 404 before falling through to /users/sign_in. Signing in with Opstella from there still works.

To make the tile behave like the others, proxy the path from the VM to the cluster Ingress in /etc/gitlab/gitlab.rb:

nginx['custom_gitlab_server_config'] = <<~NGINX
  location ^~ /clear-session {
    proxy_pass https://<ingress-lb-address>;
    proxy_set_header Host $host;
  }
NGINX

1. From Single Sign-On Page Page > Click GitLab from Code Lane and VCS Section.

2. It should redirect to GitLab Login Page with or sign in with text and Opstella button.

   

3. Click on Opstella button and check for user information.

   

SonarQube

1. From Single Sign-On Page Page > Click SonarQube from Pre-Build Lane and SAST Section.

2. It should redirect to SonarQube Login Page with Log in with Opstella.

   

3. Click on Login with Opstella and check for user information.

   

DefectDojo

1. From Single Sign-On Page Page > Click DefectDojo from Pre-Build Lane and ASPM Section.

2. It should redirect to DefectDojo Login Page with Login with Opstella.

   

3. Click on Login with Opstella and check for user information.

   

Harbor

What 'user information' should say

A user arriving through OIDC is created as a regular Harbor user: {"username":"opstella","sysadmin_flag":false}. That is the expected result of this test — being signed in as your Opstella identity, not being a Harbor administrator. If the Opstella administrators are meant to administer Harbor as well, map the group explicitly in Harbor’s OIDC settings (oidc_admin_group); it does not happen on its own.

1. From Single Sign-On Page Page > Click Harbor from Build Lane and Artifact Section.

2. It should redirect to Harbor Login Page with LOGIN WITH OPSTELLA.

   

3. Click on LOGIN WITH OPSTELLA and check for user information.

   

Vault

The tile asks which secret engine first

Vault, ArgoCD and Headlamp tiles open a dialog before leaving Opstella — Vault asks for the secret engine (one per Platform, named after it), ArgoCD and Headlamp for the Service and then the environment. The redirect only happens after that choice.

1. From Single Sign-On Page Page > Click Vault from Pre-Deploy Lane and Secrets Management Section.

2. It should redirect to Vault Login Page selecting oidc/ path (Opstella Platform SSO Integration).

   

3. Click on Sign in with OIDC Provider and check for user information.

   

ArgoCD

`No cluster assigned` on an environment that has nothing deployed

The tile asks for a Service and an environment first. Picking an environment the Service was never deployed to — production, on a Service that only has development — answers No cluster assigned. That is the correct answer for that data, not a broken ArgoCD.

หมายเหตุ

Applies to all ArgoCD instances.

1. From Single Sign-On Page Page > Click ArgoCD from Deploy Lane and Deploy Section.

2. It should redirect to ArgoCD Login Page with LOG IN VIA OPSTELLA.

   

3. Click on LOG IN VIA OPSTELLA and check for user information

   

Headlamp

หมายเหตุ

Applies to all Headlamp instances.

หมายเหตุ

The Headlamp tiles are labelled with the cluster’s API endpoint (an IP address), not with the cluster name, so pick the one matching the environment you want.

The Headlamp tile is not an SSO test

Headlamp is the one tool on this page without an OIDC login, so nothing here proves SSO — it only proves the tile deep-links to the right cluster. An environment that the Service has not been deployed to yet shows No cluster assigned, which is correct, not an error.

1. From Single Sign-On Page Page > Click Headlamp from Deploy Lane and Deploy Section.

2. It should open Headlamp for the cluster of the environment you picked.

   Headlamp as installed by Headlamp authenticates with a Service Account token, not with OIDC, so it asks you to paste a token instead of signing you in through Opstella. Create one on the matching cluster:

   kubectl create token headlamp -n devsecops-system

   Paste it into Headlamp, and you can start browsing through Kubernetes Resources.

   

Grafana Dashboard

Each Service also gets its own Grafana organization

worker-grafana creates a second organization named after the Service (<platform>-<service>) when the Service is created, holding its own Prometheus, Mimir, Loki-Opstella and Tempo-Opstella data sources that point at https://{mimir,loki,tempo}.${BASE_DOMAIN}. That is why this step insists on Main Org. — the data sources described below are a different set from the ones the worker manages.

Those service-scoped data sources go through the Ingress, so on a site whose certificate is issued by an internal CA they all fail with certificate verify failed, while the Main Org. ones (in-cluster URLs) keep working. Either give Grafana the CA (tls_client_ca in the Grafana values) or finish issuing a publicly trusted certificate before judging them broken.

หมายเหตุ

Grafana Dashboard will be the only way to access to Grafana Mimir, Grafana Loki, and Grafana Tempo (They are Data Sources of Grafana Dashboard).

If you try to click on any of Grafana Loki, and Grafana Tempo, it would redirect to Grafana Dashboard.

This is due to Application Architecture.

1. From Single Sign-On Page Page > Click Grafana from Observability Lane and Monitoring Section.

2. It should redirect to Grafana Login Page with Sign in with Opstella.

   

3. Click on Sign in with Opstella and check for user information

   

4. Verify that all Data Sources can be connected properly, Go to Left-side Menu > Connections > Data Sources. Add Data Source if not exists yet.

   Be sure to be on Main Org. for Grafana Organization.

   

   Click on + Add new data source

   

   Add these customization to ALL Type of Data Source Settings.

   • Grafana Mimir

     Type: Time series databases > Prometheus

     Name: Mimir

     URL: https://mimir.${BASE_DOMAIN}/prometheus

     

     HTTP Headers:

     • X-Scope-OrgID: opstella-platform

     

   • Grafana Loki

     Type: Logging & document databases > Loki

     Name: Loki

     URL: https://loki.${BASE_DOMAIN}

     HTTP Headers:

     • X-Scope-OrgID: opstella-platform

     

   • Grafana Tempo

     Type: Distributed tracing > Tempo

     Name: Tempo

     URL: https://tempo.${BASE_DOMAIN}

     HTTP Headers:

     • X-Scope-OrgID: opstella-platform

     

   Once you finished filling the settings, Click on Save & Test button. It should show,

   ✅ Data source successfully connected.

   

Verify without the Web Interface

The checks above are visual. Each tool also answers a request that proves which identity is signed in, which is repeatable, scriptable, and works when the browser cannot reach a tool at all. Run them with the session cookie of the browser you just signed in with (curl -b cookies.txt, or the browser’s own console):

Tool	Request	Passes when
GitLab	GET /api/v4/user	identities[].provider is openid_connect
SonarQube	GET /api/users/current	"externalProvider":"oidc"
DefectDojo	GET /profile	200, showing the Opstella user
Harbor	GET /api/v2.0/users/current	"username" is your Opstella user
Vault	GET /v1/auth/token/lookup-self	"path":"auth/oidc/login"
ArgoCD	GET /api/v1/session/userinfo	"loggedIn":true and groups is populated
Grafana	GET /api/user	"authLabels":["Generic OAuth"]
Grafana data sources	GET /api/datasources/<id>/health	"status":"OK"

หมายเหตุ

Tempo answers the health endpoint with Method not implemented — that is not a failure. Check it with GET /api/datasources/proxy/uid/<uid>/api/echo instead.