- 25 Aug, 2020 5 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
If the controller is watching resources in all namespaces (CLI option namespace is not set, helm value vikingController.namespace is undefined or empty), then define a ClusterRole as we do now. In the helm chart we use the prefix "viking.uplex.de:" in the ClusterRole's name, since ClusterRoles are not namespaced. If the controller is watching one namespace (CLI option namespace, helm value vikingController.namespace are set to the namespace), define a Role in the namespace, and a RoleBinding to connect it to the ServiceAccount. Then the restriction to the namespace is enforced by RBAC. For the viking service (Varnish/haproxy-as-Ingress implementation): in place of the ClusterRole and ClusterRoleBinding we have now, define a Role and RoleBinding in the namespace in which the Pods run. This enforces the restriction to the namespace. RBAC is needed to read TLS Secrets, which must be in the same namespace. This means that the k8s-crt-dnldr running in the haproxy container must be invoked with the namespace CLI arg. For that, we use the downward API to pass POD_NAMESPACE into the container. The namespace example is adjusted for these changes, and a Makefile drives the tests, using both helm and kubectl. The archtiectures and varnish_pod_template tests have also been adjusted, although for now these are run only with kubectl.
-
- 20 Aug, 2020 18 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 19 Aug, 2020 10 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
Invoke with: $ PATH=$PATH:/dir/for/haproxy TEST=local DEPLOY=kubectl ./test/e2e.sh The PATH to find haproxy allows tests that require it to run (otherwise they are skipped). We currently deploy with kubectl rather than helm due to naming differences.
-
Geoff Simmons authored
This made it necessary to separate the RBAC and ServiceAccount maifests for controller and varnish. We now have deploy and undeploy targets for both controller and Varnish that use helm or kubectl, depending on whether the make variable DEPLOY=kubectl is set.
-
Geoff Simmons authored
make variable DEPLOY=kubectl specifies these variants for the targets deploy- and undeploy-controller, otherwise un/deploy the helm chart.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
make VARNISH=klarlack ... # for the klarlack image, otherwise varnish make TEST=local ... # for the local docker registry make TEST=ci ... # for the gitlab registry (CI pipeline) If TEST is unset, pull the "official" images from dockerhub.
-
Geoff Simmons authored
This has the consequence that GNU make is required.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 18 Aug, 2020 5 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
Ref #36
-
Geoff Simmons authored
The haproxy container now runs the app k8s-crt-dnldr, and no longer runs http-faccess. See https://code.uplex.de/k8s/k8s-crt-dnldr k8s-crt-dnldr runs a k8s client that reads Secrets, filtered for RLS (type:kubernetes.io/tls). It provides a REST API with which a client can instruct it to write (PUT) or remove (DELETE) a pem file (concatenated crt and key) corresponding to a TLS Secret in the cluster. By default, these are written to /etc/ssl/private, where haproxy reads certificates. After the next haproxy reload following the write or delete, haproxy will use or not use the certificate. Once k8s-crt-dnldr has been instructed to store a Secret, it responds to Update and Delete events for the Secret by updating or deleting the file on its own. The controller currently sends commands to do so as well, but in practice the k8s-crt-dnldr has already changed the certificate itself (this is not an error). This means that viking Pods must have RBAC rights to read Secrets (the fact that these are filtered for TLS is not expressible in RBAC). That in turn means that viking Pods must be assigned a service account name, to get the RBAC role binding. The controller no longer needs RBAC write privileges for Secrets, and the "tls-cert" Secret with the hard-wired name is no longer necessary. The Secret volume that projects "tls-cert" into viking Pods has been removed. The port faccess in the headless Service for viking admin has been renamed to crt-dnldr. Addresses #36
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 17 Aug, 2020 2 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-