DEV Community: Gokhan Sari

Kubernetes service accounts, and creating kubeconfig for one

Gokhan Sari — Sat, 09 Nov 2024 10:59:55 +0000

A service account is a type of non-human account that, in Kubernetes, provides a distinct identity in a Kubernetes cluster.

Service accounts can be used for providing access both to components inside the cluster and other services from outside the cluster. For example, I use a service account to give access to GitHub actions to deploy new version of the WebGazer on a new release.

"But I already have a kubeconfig that I use with kubectl, managing the cluster"

Please don't copy/paste your cluster-admin role kubeconfig 🙃 If you do, that allows other party to do whatever they want to do to every resource, on every namespace, cluster-wide. Even if the tool or service you create the service account is very trustworthy, and not malicious; there might be a bug in their systems somehow accidentally editing or deleting unexpected resources.

That's why you should create a service account specific for that tool or service, and with limited permissions that is enough for what you expect the tool or service to do (see Principle of least privilege). You know, better safe than sorry.

A service account, a role and a role binding

For the GitHub actions deploying WebGazer on the cluster case, my configuration is similar to this:

ServiceAccount and its token secret

apiVersion: v1
kind: ServiceAccount
metadata:
  name: webgazer-github
  namespace: default

serviceaccount-webgazer-github.yaml

apiVersion: v1
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: webgazer-github
  name: webgazer-github-token
  namespace: default
type: kubernetes.io/service-account-token

secret-webgazer-github.yaml

Before version 1.24, Kubernetes created secret for the service account automatically. But after 1.24, we manually need to create a secret.

From kubernetes docs

Role and binding

The rules in the Role resource is the important. That is where you allow the service account to do certain stuff on the cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: webgazer-github
  namespace: default
rules:
- verbs: ["*"]
  apiGroups: ["", apps, batch, networking.k8s.io, rbac.authorization.k8s.io]
  resources: ["*"]

role-webgazer-github.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: webgazer-github
  namespace: webgazer
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: webgazer-github
subjects:
- kind: ServiceAccount
  name: webgazer-github
  namespace: default

RoleBinding

Creating kubeconfig for service account

There are some shell scripts you can find on the internet. But the most convenient method I found is Kazuki Suda's view-serviceaccount-kubeconfig kubectl plugin.

You will need krew to install that plugin, which is the most popular kubectl package I know. I used homebew to install krew:

$ brew install krew

To see other methods you can use to install krew, head over to krew's installation docs.

Once you have krew installed, you can install view-serviceaccount-kubeconfig plugin, too:

$ kubectl krew install view-serviceaccount-kubeconfig

And then you can use the plugin to create the kubeconfig:

$ kubectl view-serviceaccount-kubeconfig \
  --namespace default \
  webgazer-github

And it will output the kubeconfig's content. You can use that kubeconfig wherever you need to access the cluster with the service account you created.

Automatic PostgreSQL backups to AWS S3 (Kubernetes CronJob)

Gokhan Sari — Mon, 01 Jul 2024 16:31:00 +0000

I am not going to spend too much time explaining how important database backups are, I assume we are past that point since you are already here, reading this. But let's start with the saying:

Your data is as good as your last backup, and your backup is as good as your ability to restore it.

Here at WebGazer, we work hard to squeeze out the most valuable reports from the data collected. In addition to downtime notifications, we try to provide actionable insights that will help our customers improve their infrastructures proactively. That's why we pay great attention to integrity of our database, but every once in a while something goes south and a data migration causes some data loss, or an unforeseen case for an SQL query breaks the data. I am not going to say those times are easy. I still get anxious doing something manual on the production database, but backups, at least, ease the pain.

Anyway, let's get to the real stuff. In this tutorial, we are going to back up our PostgreSQL database, and upload the backup to AWS S3 every morning at 07:00. We are going to need:

A PostgreSQL DBMS running on a Kubernetes cluster (duh!)
An AWS S3 bucket (or something compatible)

Kubernetes CronJob

"cron" is originally a command line job scheduling utility developed in 1975 by AT&T Bell Laboratories. But ever since, "cronjob" is the common name for scheduled, periodic jobs in computer science terminology. Kubernetes has a workload type called CronJob that serves the very same purpose, and it is generally available since v1.21 (April 2021). That is what we are going to use.

postgres-s3-backup docker image

I created a docker image that uses pg_dump to create a backup for a PostgreSQL database, and uploads it to S3 using rclone. The source code for this image is available on https://github.com/th0th/postgres-s3-backup, and the docker image is available on Docker Hub, th0th/postgres-s3-backup.

This image uses environment variables for configuration, you can see all configuration options on README. Here is an example Kubernetes CronJob resource definition that uses this image (you need to replace the placeholders indicated between < >):

apiVersion: batch/v1
kind: CronJob
metadata:
  name: postgres-backup
  namespace: <NAMESPACE>
spec:
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - env:
              - name: AWS_ACCESS_KEY_ID
                value: <AWS_ACCESS_KEY_ID>
              - name: AWS_REGION
                value: <AWS_REGION>
              - name: AWS_S3_ENDPOINT
                value: <AWS_S3_ENDPOINT> # this is the path in the bucket (e.g. backups/postgres)
              - name: AWS_SECRET_ACCESS_KEY
                value: <AWS_SECRET_ACCESS_KEY>
              - name: POSTGRES_DB
                value: <POSTGRES_DB>
              - name: POSTGRES_HOST
                value: <POSTGRES_HOST> # this is hostname for the PostgreSQL service. if not set explicitly, defaults to "postgres"
              - name: POSTGRES_PASSWORD
                value: <POSTGRES_PASSWORD>
              - name: POSTGRES_PORT
                value: <POSTGRES_PORT> # if not set explicitly, defaults to "5432"
              - name: POSTGRES_USER
                value: <POSTGRES_USER> # if not set explicitly, defaults to "postgres"
              - name: POSTGRES_VERSION
                value: <POSTGRES_VERSION> # version of the PostgreSQL server. "14", "15" or "16". Defaults to "16".
              # - name: WEBGAZER_HEARTBEAT_URL
              #   value: <WEBGAZER_HEARTBEAT_MONITOR_URL> # we will talk about this in the BONUS section below
              image: th0th/postgres-s3-backup:0.2
              name: postgres-backup
  schedule: "0 7 * * *" # this runs on 07:00 every day. see https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#schedule-syntax

BONUS: Monitoring with WebGazer Heartbeat Monitoring

WebGazer offers heartbeat monitoring for making sure cron jobs like this run as they are supposed to. It basically works like this: you set a heartbeat monitor on WebGazer, send programmatic HTTP requests from the cron job to that monitor's URL. If the monitor doesn't get the request in time, it alerts you. So you get to know if a database backup isn't completed at the time it should be completed.

The docker image I mentioned has this built-in, just uncomment the lines near the end, and set the WEBGAZER_HEARTBEAT_URL to the heartbeat monitor's URL you get from WebGazer, and you are good to go.

- name: WEBGAZER_HEARTBEAT_URL
  value: https://heartbeat.webgazer.io/1-GjluPbM8GIu15xkC9mQDRtfxJBmAGa7P

Additionally, when WEBGAZER_HEARTBEAT_URL is set, this docker image reports a heartbeat parameter called seconds, total seconds it takes to take the database backup and upload it to S3, you can add a rule to the heartbeat monitor, too.

I built the free and open source, privacy-first Google Analytics alternative

Gokhan Sari — Mon, 29 May 2023 13:59:50 +0000

Hey folks!

For about the last two years, I have been working on this. I have recently published it, so I want to share with you all, and ask for your feedback, too!

Some highlights you might find interesting are:

✊ It is 100% free and open source (AGPL).
✌️ It doesn't collect any personal data, so it is out-of-the-box compliant with data privacy regulations like GDPR, CCPA, PECR and KVKK.
🎯 It is simple analytics. It provides consolidated real-time reports on a single-page.
🪶 It has a very lightweight (< 1KB) script. It doesn't cause any harm on the website's performance.

You can see a demo of the reports page here.

Even though you can see the stack yourself on the repository, here are some of the stuff I used building it:

Go for backend,
Next.js (TypeScript, Bootstrap) for frontend,
PostgreSQL for the single source of truth database,
ClickHouse for time series analytics data,
and RabbitMQ as the task queue.

You can give it a go on poeticmetric.com, and the check its full source code on https://github.com/th0th/poeticmetric. I also published ready-to-use Docker images for self-hosting (guide here).

I would love to what you think of it!

Cheers,