trustbloc / k8s Goto Github PK

Similar to #16

After switching to GNAP auth for Wallet, we don't need the following components.

• Auth hydra
• Authz KMS
• Authz KMS Oathkeeper
• Ops KMS
• Ops KMS Oathkeeper
• EDV Oathkeeper
• Wallet Server

need to match the base-line version of k8s in trustbloc/sandbox, client-side.

Currently, both issuer and rp adapter are bundled into single folder. Due to this, we can't deploy individual components.

local overlay should only have ingress and self-signed pki

Add it to the json-ld context server - https://github.com/trustbloc/k8s/tree/main/dbs/kustomize/dbs/components/static-file-server

Context - https://w3id.org/traceability/v1
Reference - https://hackmd.io/TBvSW7uJRGGzblFpdBg4xg

De-duplicate scripts in https://github.com/trustbloc/sandbox/tree/main/k8s/scripts and https://github.com/trustbloc/k8s/tree/main/scripts

This should be based on environment, eg, stg - TrustBloc Wallet - Staging, sandbox - TrustBloc Wallet - Sandbox, etc. We can create a new PR to refactor this.

Originally posted by @rolsonquadras in #250 (comment)

We renamed the repo and related docker images for the TrustBloc Router service from hub-router to mediator. The change needs to be updated in deployments as well.

We renamed the repo and related docker images for the TrustBloc Auth service from hub-auth to auth. The change needs to be updated in deployments as well.

With minikube v1.19.0, the deployment fails with following error (macOS and linux). This works fine on v1.18.0

Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": an error on the server ("") has prevented the request from succeeding

Use latest from universalregistrar/uni-registrar-web:latest instead of honeyblock/uni-registrar-web:custom_v1.0

CI runner uses v4.3.0.

except for orb, jobs are primary needed to facilidate running demo and perform validation (end-to-end web flows) through ui-automation. This will also eliminate drift when these jobs/scripts are consumed elsewhere.

Crypto material for components gets generated as part of an openssl container run on the host. To align with the overall workflow, and weed-out architecture discrepancies, it should be replaced with a pod invocation.

There are plans to deprecate vars. replacements provide an expanded scope.

similar to RP adapter PEx - https://github.com/trustbloc/k8s/blob/main/adapter-rp/kustomize/adapter-rp/overlays/common/rp/config.json

deploy-with-external-mongodb is mentioned in the docs but that make target doesn't exist anywhere. Should this be removed?

(Used to be called deploy-with-external-couchdb - still didn't exist then)

https://github.com/kubernetes/minikube/releases/tag/v1.22.0

Hub-auth fails to start-up if one of the providers is not available. We need to update hub-auth to remove the checks on start-up and add the deployment config in this repo.

Currently, orb exposes a simple /healthcheck endpoint to signal container liveness. another endpoint (/.well-known/nodeinfo) reflects completing the startup sequence and "readiness" to serve requests.
adding this will eliminate the false-positves of orb being up but in fact its still not.

Add VCS component along with support for Gateway+Auth

Tasks:

• Add VCS Component
• Add Auth(Hydra) component
• Add Gateway/Proxy (Oathkeeper) component

The generate-test-keys Makefile target uses frapsoft/openssl, which only has an amd64 version. While this does seem to work currently (as it seems that Docker makes use of QEMU to support emulation of non-native architectures), it would still be a good idea to find an alternative that supports both amd64 and arm64 natively for better performance and to avoid potential issues.