chart: name the configured auth type in the issuer failure, fix a doc default

Both oidc and dex take tap.auth.oidc.issuer, but the failure hard-coded "oidc",
so a dex operator was sent looking for a setting they had not configured.

The README also documented tap.auth.rolesClaim as `role` where the chart
defaults it to `groups`, which is the kind of mismatch an operator only finds
after their SSO claims fail to map.

helm-chart/README.md

@@ -215,7 +215,7 @@ Example for overriding image names:
 | `tap.auth.type`                           | Authentication backend. Valid values: `saml`, `oidc` (generic OIDC — Dex, Okta, Auth0, Keycloak, Azure AD, Google, …), `dex` (permanent alias of `oidc`), `descope`, `default` (also routes to Descope). **Breaking**: prior releases routed `oidc` to Descope — if you were using it for Descope, switch to `descope` or `default`. | `saml`                                                                                                                                                                                                                                           |
 | `tap.auth.approvedEmails`                 | List of approved email addresses for authentication              | `[]`                                                                                                                                                                                                                                             |
 | `tap.auth.approvedDomains`                | List of approved email domains for authentication                | `[]`                                                                                                                                                                                                                                             |
-| `tap.auth.rolesClaim`                     | Name of the JWT claim (OIDC) or SAML attribute carrying role memberships. | `role` |
+| `tap.auth.rolesClaim`                     | Name of the JWT claim (OIDC) or SAML attribute carrying role memberships. | `groups` |
 | `tap.auth.defaultRole`                    | Role applied when a caller has no matching role. Respected whether or not `tap.auth.enabled` is set: with authentication off it is the role every caller gets, so `kubeshark-viewer` yields a read-only deployment with no login. One of the built-in roles (`kubeshark-admin`, `kubeshark-realtime`, `kubeshark-snapshot`, `kubeshark-viewer`) or a role name from `tap.auth.roles`. With authentication on, an empty string means no fallback and therefore no permissions; with it off, an empty or unrecognized value falls back to `kubeshark-admin` so an install that never configured authorization keeps working. | `kubeshark-admin` |
 | `tap.auth.roles`                          | Backend-neutral role map shared by SAML and OIDC. Each role's `namespaces` is a comma-separated list controlling which Kubernetes namespaces the role's users see traffic for: `""` = deny all, `"*"` = allow all, `"foo"` = literal namespace, `"foo,bar"` = OR over literals, `"foo-*"` = glob expansion against the cluster's known namespaces. Empty/unset `tap.auth.roles` grants nothing — admins opt into elevated access by populating this map. | `{"admin":{"namespaces":"*","canDownloadPCAP":true,"canUpdateTargetedPods":true,"canUseScripting":true,"scriptingPermissions":{"canSave":true,"canActivate":true,"canDelete":true},"canStopTrafficCapturing":true,"canControlDissection":true,"showAdminConsoleLink":true}}` |
 | `tap.auth.cli.enabled`                    | Enable ServiceAccount-token auth for the CLI. Creates a `kubeshark-cli` ServiceAccount plus a Role permitting `create` on its token, and allowlists it on the hub via `AUTH_CLI_SERVICE_ACCOUNTS`. The CLI mints a short-lived token for that SA to authenticate to a gated hub. Map `kubeshark-cli` to a role via `tap.auth.groupMapping`; without a mapping it falls back to `tap.auth.defaultRole`. | `false` |

helm-chart/templates/_helpers.tpl

@@ -130,7 +130,7 @@ authenticates nobody.
     {{- fail "tap.auth.enabled is true with tap.auth.type=saml but tap.auth.saml.idpMetadataUrl is empty. Set the IdP metadata URL, or pick another tap.auth.type (oidc, dex, descope)." -}}
   {{- end -}}
   {{- if and (or (eq .Values.tap.auth.type "oidc") (eq .Values.tap.auth.type "dex")) (empty (((.Values.tap).auth).oidc).issuer) -}}
-    {{- fail "tap.auth.enabled is true with tap.auth.type=oidc but tap.auth.oidc.issuer is empty. Set the OIDC issuer, or pick another tap.auth.type." -}}
+    {{- fail (printf "tap.auth.enabled is true with tap.auth.type=%s but tap.auth.oidc.issuer is empty. Set the OIDC issuer, or pick another tap.auth.type." .Values.tap.auth.type) -}}
   {{- end -}}
 {{- end -}}
 {{- end -}}

helm-chart/tests/auth_validation_test.yaml

@@ -91,3 +91,15 @@ tests:
       - equal:
           path: data.AUTH_TYPE
           value: oidc
+
+  ## The message names the type the operator actually set. Both oidc and dex
+  ## take the same issuer, so a hard-coded "oidc" sends a dex operator looking
+  ## for a setting they did not configure.
+  - it: names dex in the failure when dex is the configured type
+    set:
+      tap.auth.enabled: true
+      tap.auth.type: dex
+      tap.auth.oidc.issuer: ""
+    asserts:
+      - failedTemplate:
+          errorMessage: "tap.auth.enabled is true with tap.auth.type=dex but tap.auth.oidc.issuer is empty. Set the OIDC issuer, or pick another tap.auth.type."