Dustin
f468977d91
I discovered today that if anonymous Grafana users have Viewer permission, they can use the Datasource API to make arbitrary queries to any backend, even if they cannot access the Explore page directly. This is documented ([issue #48313][0]) as expected behavior. I don't really mind giving anonymous access to the Victoria Metrics datasource, but I definitely don't want anonymous users to be able to make Loki queries and view log data. Since Grafana Datasource Permissions is limited to Grafana Enterprise and not available in the open source version of Grafana, the official recommendation from upstream is to use a separate Organization for the Loki datasource. Unfortunately, this would preclude having dashboards that have graphs from both data sources. Although I don't have any of those right now, I like the idea and may build some eventually. Fortunately, I discovered the `send_user_header` Grafana configuration option. With this enabled, Grafana will send an `X-Grafana-User` header with the username of the user on whose behalf it is making a request to the backend. If the user is not logged in, it does not send the header. Thus, we can detect the presence of this header on the backend and refuse to serve query requests if it is missing. [0]: https://github.com/grafana/grafana/issues/48313 |
||
|---|---|---|
| argocd | ||
| authelia | ||
| autoscaler | ||
| cert-manager | ||
| dch-root-ca | ||
| dch-webhooks | ||
| device-plugins | ||
| docker-distribution | ||
| dynk8s-provisioner | ||
| firefly-iii | ||
| grafana | ||
| home-assistant | ||
| hudctrl | ||
| ingress | ||
| invoice-ninja | ||
| jenkins | ||
| keyserv | ||
| kitchen | ||
| loki-ca | ||
| metrics | ||
| ntfy | ||
| paperless-ngx | ||
| photoframesvc | ||
| phpipam | ||
| postgresql | ||
| prometheus_speedtest | ||
| rent-reminder | ||
| scanservjs | ||
| sealed-secrets | ||
| setup | ||
| sshca | ||
| step-ca | ||
| storage | ||
| victoria-metrics | ||
| websites | ||
| xactfetch | ||
| README.md | ||
README.md
Dustin's Kubernetes Cluster
This repository contains resources for deploying and managing my on-premises Kubernetes cluster
Cluster Setup
The cluster primarily consists of libvirt/QEMU+KVM virtual machines. The Control Plane nodes are VMs, as are the x86_64 worker nodes. Eventually, I would like to add Raspberry Pi or Pine64 machines as aarch64 nodes.
All machines run Fedora, using only Fedora builds of the Kubernetes components
(kubeadm, kubectl, and kubeadm).
See Cluster Setup for details.
Jenkins Agents
One of the main use cases for the Kubernetes cluster is to provide dynamic agents for Jenkins. Using the Kubernetes Plugin, Jenkins will automatically launch worker nodes as Kubernetes pods.
See Jenkins Kubernetes Integration for details.
Persistent Storage
Persistent storage for pods is provided by Longhorn. Longhorn runs within the cluster and provisions storage on worker nodes to make available to pods over iSCSI.
See Persistent Storage Using Longorn for details.