KNOX-3364: New loadAliasesFromK8sSecrets method in entrypoint.sh to l…

[hanicz]

…oad aliases from k8s secrets. Install jq in the container as well.

KNOX-3364 - Bootstrap Knox aliases from labeled Kubernetes Secrets on container startup

What changes were proposed in this pull request?

Helper function to load Knox aliases from labeled Kubernetes Secrets. Uses the pod's mounted ServiceAccount token to list Secrets in the pod's namespace that carry KNOX_ALIAS_LABEL and feeds the names to knoxcli create-k8s-alias, so aliases are restored on every pod restart. Skips silently when no ServiceAccount token is mounted (non-k8s runs); logs a warning and continues on API errors so Knox startup isn't blocked by transient cluster issues. Requires: jq in the image; the pod's ServiceAccount must have list on Secrets in its namespace.

• Installs jq on the container

How was this patch tested?

Tested on a local kind cluster, tested by just running without k8s, tested with no secrets, tested with different labels

Secrets:

---
apiVersion: v1
kind: Secret
metadata:
  name: stringdatasecret
  namespace: knox
  labels:
    knox.apache.org/alias: "true"
type: Opaque
stringData:
  alias.name: my-alias2
  topology: sandbox
  alias.value: s3cr3t
---
apiVersion: v1
kind: Secret
metadata:
  name: datasecret
  namespace: knox
  labels:
    knox.apache.org/alias: "true"
type: Opaque
data:
  alias.name: bXktYWxpYXM=
  alias.value: czNjcjN0

./bin/knoxcli.sh list-alias --cluster __gateway,sandbox

[github-actions]

Test Results

28 tests   28 ✅  3s ⏱️
 1 suites   0 💤
 1 files     0 ❌

Results for commit 9651977.

[smolnar82]

Just a minor observation on the curl command, it's not a blocker...

[smolnar82]

nit: there's no explicit timeout on the curl call. If the k8s API is slow or unreachable, this could stall container startup. Adding --max-time 10 or similar would make the failure path faster.