content/en/docs/solution/tools/CNOE/idpbuilder/http-routing.md

@@ -0,0 +1,57 @@
+---
+title: Http Routing
+weight: 100
+---
+
+### Routing switch
+
+The idpbuilder supports creating platforms using either path based or subdomain
+based routing:
+
+```shell
+idpbuilder create --log-level debug --package https://github.com/cnoe-io/stacks//ref-implementation
+```
+
+```shell
+idpbuilder create --use-path-routing --log-level debug --package https://github.com/cnoe-io/stacks//ref-implementation
+```
+
+However, even though argo does report all deployments as green eventually, not
+the entire demo is actually functional (verification?). This is due to
+hardcoded values that for example point to the path-routed location of gitea to
+access git repos. Thus, backstage might not be able to access them.
+
+Within the demo / ref-implementation, a simple search & replace is suggested to
+change urls to fit the given environment. But proper scripting/templating could
+take care of that as the hostnames and necessary properties should be
+available. This is, however, a tedious and repetitive task one has to keep in
+mind throughout the entire system, which might lead to an explosion of config
+options in the future. Code that addresses correct routing is located in both
+the stack templates and the idpbuilder code.
+
+### Cluster internal routing
+
+For the most part, components communicate with either the cluster API using the
+default DNS or with each other via http(s) using the public DNS/hostname (+
+path-routing scheme). The latter is necessary due to configs that are visible
+and modifiable by users. This includes for example argocd config for components
+that has to sync to a gitea git repo. Using the same URL for internal and
+external resolution is imperative.
+
+The idpbuilder achieves transparent internal DNS resolution by overriding the
+public DNS name in the cluster's internal DNS server (coreDNS). Subsequently,
+within the cluster requests to the public hostnames resolve to the IP of the
+internal ingress controller service. Thus, internal and external requests take
+a similar path and run through proper routing (rewrites, ssl/tls, etc).
+
+### Conclusion
+
+One has to keep in mind that some specific app features might not
+work properly or without haxx when using path based routing (e.g. docker
+registry in gitea). Futhermore, supporting multiple setup strategies will
+become cumbersome as the platforms grows. We should probably only support one
+type of setup to keep the system as simple as possible, but allow modification
+if necessary.
+
+DNS solutions like `nip.io` or the already used `localtest.me` mitigate the
+need for path based routing

content/en/docs/solution/tools/kyverno integration/_index.md

@@ -1,7 +1,7 @@
-+++
-title = "Kyverno integration"
-weight = 4
-+++
+---
+title: Kyverno
+description: Kyverno is a policy engine for Kubernetes designed to enforce, validate, and mutate configurations of Kubernetes resources
+---
 
 ## Kyverno Overview