fix(k8s): fix JAVA_HOME

[achrinza]

Updates the JAVA_HOME env var for the build-uaa-truststore init contianer to match the updated path used by the Paketo buildpack.

fixes: #2388

---

With this PR, the UAA k8s ytt template with local_testing.yml addon will deploy, but wont wont be "usable" as jwt.policy.keys.FAKE_JWT_SIGNING_KEY_DO_NOT_USE still needs to be patched with a valid private key to prevent UAA from rejecting its own tokens.

I did not include that patch here as I'm not sure if that "was used for anything else.

[strehle]

mentioned in discussion with broadcom... ok for SAP.

before it was more generic, now it is pinned to a product name, but we dont use k8s

[coolgang123]

We don't use k8s either. As @strehle mentioned in the issue, k8s is not supported.

@achrinza could you specify how have you tested the fix please?

[achrinza]

@coolgang123 Some info on how we tested the k8s deployment:

@achrinza could you specify how have you tested the fix please?

There's two more files needed to properly deploy and test (I'm happy to add these changes to this PR):

1. ingress.yaml - Creates an ingress.
   The file k8s/addons/ingress.yml uses the old Ingress API which is no longer supported.

2. jwt.yaml - Adds a valid private key for JWT signing (copied from the SAML key)
   k8s/addons/local_testing.yml does not provide a valid private key, which causes UAA to reject its own JWT tokens.

This is the minimal deployment steps from start to finish:

$ git clone https://github.com/cloudfoundry/uaa.git

$ cat <<EOF >>ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: uaa-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: uaa
            port:
              number: 8080
EOF

$ cat <<EOF >>jwt.yaml
#@data/values
#@ load("@ytt:overlay", "overlay")
---
#@overlay/replace
jwt:
  policy:
    activeKeyId: FAKE_JWT_SIGNING_KEY_DO_NOT_USE
    keys:
      FAKE_JWT_SIGNING_KEY_DO_NOT_USE:
        signingKey: |
          -----BEGIN RSA PRIVATE KEY-----
          MIICXQIBAAKBgQDHtC5gUXxBKpEqZTLkNvFwNGnNIkggNOwOQVNbpO0WVHIivig5
          L39WqS9u0hnA+O7MCA/KlrAR4bXaeVVhwfUPYBKIpaaTWFQR5cTR1UFZJL/OF9vA
          fpOwznoD66DDCnQVpbCjtDYWX+x6imxn8HCYxhMol6ZnTbSsFW6VZjFMjQIDAQAB
          AoGAVOj2Yvuigi6wJD99AO2fgF64sYCm/BKkX3dFEw0vxTPIh58kiRP554Xt5ges
          7ZCqL9QpqrChUikO4kJ+nB8Uq2AvaZHbpCEUmbip06IlgdA440o0r0CPo1mgNxGu
          lhiWRN43Lruzfh9qKPhleg2dvyFGQxy5Gk6KW/t8IS4x4r0CQQD/dceBA+Ndj3Xp
          ubHfxqNz4GTOxndc/AXAowPGpge2zpgIc7f50t8OHhG6XhsfJ0wyQEEvodDhZPYX
          kKBnXNHzAkEAyCA76vAwuxqAd3MObhiebniAU3SnPf2u4fdL1EOm92dyFs1JxyyL
          gu/DsjPjx6tRtn4YAalxCzmAMXFSb1qHfwJBAM3qx3z0gGKbUEWtPHcP7BNsrnWK
          vw6By7VC8bk/ffpaP2yYspS66Le9fzbFwoDzMVVUO/dELVZyBnhqSRHoXQcCQQCe
          A2WL8S5o7Vn19rC0GVgu3ZJlUrwiZEVLQdlrticFPXaFrn3Md82ICww3jmURaKHS
          N+l4lnMda79eSp3OMmq9AkA0p79BvYsLshUJJnvbk76pCjR28PK4dV1gSDUEqQMB
          qy45ptdwJLqLJCeNoR0JUcDNIRhOCuOPND7pcMtX6hI/
          -----END RSA PRIVATE KEY-----
EOF

$ ytt \
    --file ./uaa/k8s/templates/ \
    --file ./uaa/k8s/addons/local_testing.yml \
    --file jwt.yaml \
    --file ingress.yaml | kubectl apply -f -

$ uaa target "http://[K8s Public IP]:8080"

$ uaa get-client-credentials-token \
    admin \
    --client_secret 'FAKE_ADMIN_CLIENT_SECRET'

$ uaa list-groups # Verifies that the generated JWT token is valid

We're using UAA on k8s internally as an app idP, which has been working well so far, and have used the k8s templates as a starting point.

As @strehle mentioned in the issue, k8s is not supported

The manifests and images have been a useful starting point for UAA on k8s without needing to dig through the codebase or build a k8s deployment from scratch. So I'd hope it can be kept on a "best effort" basis (i.e. better something than nothing).