GitLab DACH Roadshow 2025 | Düsseldorf

<p>Auch in diesem Jahr besuchte codecentric wieder die JavaOne in San Francisco, die zum ersten mal zeitgleich zur Oracle Open World stattfindet. Das bedeutet knapp 50.000 Besucher im Zentrum von San Francisco und eine damit verbundene organisatorische Meisterleistung von Oracle.</p><p><a href="/wissens-hub/blog/javaone-2010"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ayOlAHwoSseoj5HgNluO" alt width="540" height="404" /></a> </p><p>Wie schon im Vorjahr waren <a href="/en/knowledge-hub/blog/javaone-2009-ria-development-with-javafx-2" target="_blank">JavaFX</a> , Cloud-Computing, JEE und JavaME die Top Themen der Konferenz.</p><p><span>Spannend bleibt die Entwicklung und Zukunft von JavaME. Oracle scheint unseres Erachtens nach sehr daran gelegen diese Technologie zu pushen. Hier sind nicht nur mobile Endgeräte, sondern auch Fernseher und andere Consumer Endgeräte als Zielplattform anvisiert. Im Bereich der mobilen Endgeräte wurde gerne darauf hingewiesen auf wie vielen Geräten Java heute schon läuft. Scheinbar versucht Oracle dem Trend der Smartphones entgegen zu wirken.</span></p><p>Wie man es auch sonst von der JavaOne gewöhnt ist, tummeln sich im Konferenzgeschehen wieder eine Vielzahl von bekannten Vertretern der Java-Community. Kirk Pepperdine und Dr. Heinz Kabutz sind vielleicht einigen von unseren meettheexperts-Veranstaltungen in guter Erinnerung geblieben. Neben einer BOF-Session von Heinz, wo er nochmal auf die letzten Jahre seines <a href="http://www.javaspecialists.eu/archive/archive.jsp" target="_blank">JavaSpecialist</a> -Newsletters zurückgeblickt hat, wurde von den Java-Champions die Concurrent-API und deren Anwendungsfälle mit einem kleinen <a href="http://sourceforge.net/projects/javaconcurrenta/" target="_blank">Tool</a>  visualisiert. Adam Bien durfte natürlich auch nicht fehlen. Er demonstrierte in der einzigen nicht ausgebuchten JEE6-Session, wie man mit wenigen Handgriffen und den Verzicht auf jegliche Frameworks eine JEE-Anwendung mit Netbeans erstellt. Zukünftigen Besuchern der JavaOne kann an dieser Stelle nur empfohlen werden sich rechtzeitig mit seiner Sessionplanung zu beschäftigen und im Vorfeld online eine Reservierung durchzuführen. Die Erfahrung hat gezeigt, dass gerade die Buzzword-Sessions hoffnungslos überfüllt waren und man ohne Reservierung oft keine Chance auf Einlass hatte.</p><p>Am Dienstag Abend wurden wir von Oracle zum German Community Abend im Velvet Room des <a href="http://www.clifthotel.com/" target="_blank">Hotel Clift</a>  eingeladen. Bei einem hervorragendem Diner konnten wir nette Gespräche mit vielen interessanten Persönlichkeiten führen. Danke dafür an Oracle.</p><p>Mittwoch Abend gab es dann eine weitere Einladung zum Oracle Appreciation Event. Mit Bussen wurden die Teilnehmer zu einer <a href="http://de.wikipedia.org/wiki/Treasure_Island_%28Kalifornien%29" target="_blank">künstlich angelegten Insel</a>  in der San Francisco Bay gebracht. Das Event der Superlative bot uns unter Anderem eine sehr gute Verköstigung im Kirmes-Stil mit allem was dazu gehört, inklusive Riesenrad und Free-Fall-Tower.</p><p><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/vXEoT2ehTVOK64sINm7V" alt width="540" height="405" /></p><p>Ganz nebenbei gab es dann noch ein gigantisches Konzert der Black Eyed Peas mit Blick auf die San Francisco Bridge und die Lichter im Hafen von Oakland.</p><p><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ep6aWMMeScmjrmEY1arF" alt width="540" height="405" /><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cvK4TlGBRSuOKwYlEzQr" alt width="540" height="405" /></p><p>Zu Zeiten von Sun wäre ein solches Event wohl nicht möglich gewesen. Auch hierfür nochmal Danke an Oracle.</p>

JavaOne 2010

Geschäftsführer cc cloud GmbH

Managing Director cc cloud GmbH

Partner Manager & Customer Success Manager

Du hast Fragen oder möchtest dich zu deinen Herausforderungen austauschen? Gern – trag einfach deine Kontaktdaten ein.

Kontaktanfrage | Sales (allgemein)

Kontakt

Kontaktiere uns

Du hast noch Fragen zum Event oder möchtest dich anderweitig austauschen?

Noch Fragen?

Die GitLab DACH Roadshow 2025 macht Halt in Düsseldorf und wir sind dabei!

<p>A performant and well integrated CI/CD environment is one of the key factors for fast and agile software development. To achieve short feedback cycles and increase development speed, jobs need to be as fast as possible and – ideally – should start instantly to keep the runtime of your pipeline as low as possible.<br /> This blog post will explain how to speed up your Kubernetes-based CI/CD infrastructure.</p><h2>CI/CD with GitLab and Kubernetes</h2><p>We use GitLab as our code-management tool. GitLab ships with a fully integrated CI/CD solution that supports executing your jobs on a Kubernetes cluster with the Kubernetes executor. Using this executor on an auto-scaling Kubernetes cluster can be a great way to have a dynamic CI/CD environment. This setup is capable of automatically providing to your users what they need in terms of resources. At the same time, costs are only caused when resources are used since auto-scaling is enabled.<br /> For each CI job that’s triggered via a GitLab pipeline, the runner creates a new pod in the cluster. Therefore, there is usually a highly varying workload on the cluster with peak times and low times, often depending on the time of day.<br /> Adding auto-scaling to such a cluster setup can be achieved with the <a href="https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler">Cluster-Autoscaler</a> . This tool scales your cluster to an absolute minimum in times with only a few or no build jobs at all and scales out to a bunch of nodes, if a lot of jobs need to be processed.</p><table><tbody><tr><th><strong>How does the Cluster-Autoscaler work?</strong></th></tr><tr><td><p>The Cluster-Autoscaler adds new nodes to the cluster if there are pods in the “unschedulable” state. With the default scan-interval, a scale-up is triggered up to 10 seconds after a pod was marked unschedulable.</p><dl><dt>unschedulable</dt><dd>A pod is considered unschedulable if there is no node suitable to host the workload. This might be the case if, for example, all resources are exhausted.</dd></dl><p>It shuts down nodes if they are unneeded for at least 10 minutes. Nodes are unneeded if they are empty or the workload can be shifted to the remaining nodes. Please refer to the <a href="https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-types-of-pods-can-prevent-ca-from-removing-a-node">documentation</a>  to obtain more information on when pods are considered shiftable.</p></td></tr></tbody></table><h3>The problem with autoscaling in CI/CD environments</h3><p>The runner will schedule a pod for every CI job from a GitLab Pipeline. If there are free capacities in the cluster, this pod will almost immediately start and run your code. But what if the cluster’s resources are already fully allocated?<br /> Depending on your setup and the chosen cloud provider, a scale up may need some time – up to 5 minutes (k8s-related initialization included), even on famous cloud providers like AWS, GCP or Azure. Assuming the worst-case scenario – adding 5 minutes to nearly every job – no matter if the job needs 5s or 20m? That may lead to very unhappy users and a lot of inefficiency.</p><h2>Use overprovisioning to reduce startup overhead</h2><p>One way to solve the previously described problem is overprovisioning.<br /> Overprovisioning means that the cluster always provides some more resources than actually needed. With overprovisioning in place, we could make sure that there are always some resources available, so that your CI jobs won’t have to wait for new capacities to become available.</p><p>Unfortunately, this is not a built-in feature of the cluster-autoscaler. To achieve cluster-size dependent overprovisioning, the team providing the cluster-autoscaler proposes a <a href="https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-can-i-configure-overprovisioning-with-cluster-autoscaler">solution in their FAQs</a> , using the Cluster-Proportional Autoscaler (short: CPA) and a placeholder deployment.</p><h3>How does the proposed solution work?</h3><p>To achieve overprovisioning, you’d only need the placeholder deployment. Proposed is a deployment based on the pause-image. The only purpose of these pods is to allocate the configured amount of resources.<br /> To benefit from the additional, allocated resources, the pause pods need to be evicted immediately if a build job is scheduled. This can be achieved using the <code>PriorityClass</code>-resource in Kubernetes. By assigning a PriorityClass with a low priority to the placeholders and a PriorityClass with a higher priority to the rest, Kubernetes will remove the pause pods in favour of the CI job.<br /> Because the placeholder is controlled by a deployment controller, the stopped pods will be rescheduled. If there are no resources left to allocate in the cluster, the pod becomes unschedulable and the cluster-autoscaler triggers a scale-up of the nodes.</p><p>To improve the very static approach above, the FAQs suggest to use the Cluster-Proportional Autoscaler. The CPA is a tool which is capable of scaling a target resource based on the actual cluster size. It constantly checks how many nodes are part of the cluster (alternatively checks for sum of CPU cores) and adapts the number of replicas for the target resource as configured. With this component in place, you can control the amount of placeholder pods based on cluster-size.</p><table><tbody><tr><th><strong>Examples</strong></th></tr><tr><td><p>For example, you can configure the CPA in a way that it always scales the target to half as many replicas as there are CPU cores.<br /> Alternatively, you can define a ladder function, like: scale to 2 replicas if the cluster-size is up to 5 nodes, and to 7 replicas if the cluster size is more than 5 nodes.</p></td></tr></tbody></table><h2>A Helm chart to rule them all</h2><p>At the time of writing this blog post, there was no Helm chart that installs all necessary components in your cluster. There is a fairly new Helm chart for the CPA, which can be found <a href="https://github.com/kubernetes-sigs/cluster-proportional-autoscaler/tree/master/charts/cluster-proportional-autoscaler">here</a> . To deploy the placeholder deployment and the Priority-Class setup, one could use <a href="https://github.com/deliveryhero/helm-charts/tree/master/stable/cluster-overprovisioner">this helm-chart</a>  by Delivery Hero.</p><p>But, to make the installation as smooth and integrated as possible, we decided to create yet another Helm chart, combining both of the components and adding the possibility to use different overprovisioning configurations using schedules.<br /> You can find the new Helm chart called <a href="https://github.com/codecentric/cluster-overprovisioner">cluster-overprovisioner</a>  on Github.</p><p>Without much configuration, this Helm chart deploys the CPA and a placeholder, called overprovisioning (OP), deployment as the target including the PriorityClass setup for evicting the pause pods. The only thing that should be adapted to your needs is the <code>defaultConfig</code> and the <code>op.resources</code> block. Examples and explanations for the former can be found in the Readme or the examples folder in the repo.<br /> The latter one needs to be adapted to your use-case. In our case, we decided that each pause pod should reserve capacity for an average CI job.</p><table><tbody><tr><th><strong>Example configuration with descending replicas</strong></th></tr><tr><td><p>Currently, we use the following configuration:</p><div>

```yaml
ladder:
  {
    "nodesToReplicas":
    [
      [ 0,7 ],
      [ 8,4 ],
      [ 12,0 ]
    ]
  }
```

</div><p>We have more overprovisioning for smaller cluster sizes and disable it completely if the cluster grows bigger than 12 nodes.<br /> We assumed, based on the default runtime of our CI jobs, that the bigger the cluster is, the more likely it becomes for some of the pods to be about to be terminated and space to be freed up for new build jobs. Therefore, we use the ladder mode with descending replicas the bigger the cluster becomes.</p></td></tr></tbody></table><h2>Use schedules to keep your bill under control</h2><p>Assuming most of your devs are working within the same or similar time zone, you most definitely can define time frames, in which you can waive the start-up boost given by overprovisioning in favour of reducing your compute cost. Therefore we introduced a scheduling feature into our chart. This feature is based on CronJobs. It enables you to provide different configurations for the CPA using cron expressions.</p><div>

```yaml
schedules:
  - name: night
    # disable overprovisioning Monday - Friday from 6pm
    cronTimeExpression: "0 18 * * 1-5"
    config:
      ladder:
        {
          "nodesToReplicas":
          [
            [ 0,0 ]
          ]
        }
  - name: day
    # enable overprovisioning Monday - Friday from 7am
    cronTimeExpression: "0 7 * * 1-5"
    config:
      ladder:
        {
          "nodesToReplicas":
          [
            [ 0,7 ],
            [ 8,4 ],
            [ 12,0 ]
          ]
        }
```

</div><p>For example, we have these schedules installed in our CI cluster. The night schedule completely disables overprovisioning after 6pm and on weekends. We do have scheduled jobs that run at night or even on weekends. For these the longer startup-time does not matter, as no one is waiting for the jobs to complete.<br /> Another schedule, called day, increases the amount of overprovisioning from 7am on Monday to Friday to the desired amount.</p><p>As you can imagine, adding overprovisioning to your cluster increases your total costs. Instead of providing the same amount of overprovisioning 24/7, we strongly recommend making use of the schedules. This way, you achieve the best balance between low startup times and additional costs.</p><h2>Conclusion</h2><p>CI/CD infrastructures on Kubernetes benefit very much from adding autoscaling to the cluster. It reduces compute costs to an absolute minimum in times without build jobs and is capable of handling the busiest times. Implementing overprovisioning in this setup reduces the startup-times of your jobs. To minimize the additional costs added by the overprovisioning, we introduced a scheduling feature, with which you can enable overprovisioning only in times when it’s needed and achieve a good balance between performance and costs.</p>

Speed up your CI/CD jobs in Kubernetes

Last month, Kubernetes 1.25 was released. And with that, the <a href="https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/" target="_blank">long-announced removal of PodSecurityPolicies</a> (short: PSPs) finally becomes reality. Finally? Yes – as Tabitha Sable from the Kubernetes SIG Security Team said herself in the linked blog post – PSPs were both confusing and unhandy to use.

<figure>
  <blockquote>
The way PSPs are applied to Pods has proven confusing to nearly everyone that has attempted to use them.
  </blockquote>
  <figcaption>— Tabitha Sable</figcaption>
</figure>

Spoiler: Although I’ll shed some light on PSPs in the first part of this post, and you may not have made use of them yet, I strongly encourage you to read on to learn about more powerful and easier-to-use substitutes for ensuring pod security.

## The general idea behind PSPs & Co.
But, before we get into any details, let’s take one step back and understand how PSPs (and their potential replacements) contribute to securing your workloads.

###  (Pod) Security Context
When you define your application (as a Deployment, StatefulSet, Pod ... you name it), you can set a <a href="https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" target="_blank">SecurityContext</a> to either the whole Pod or on a per-container basis. Within the SecurityContext, you can configure a lot of fields, which then will be processed by kubelet and your container runtime as instructions on how to run your pod.

```yaml
securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
  privileged: false
```

For example, you could set `runAsNonRoot: true` and with that the runtime will check if any user with uid greater than 0 is set.
To wrap up this (very) little sidenote: via the (Pod)SecurityContext object, you can actually set the conditions under which the pod has to run. Kubernetes will make sure that the pods fit to the configured settings and will fail their deployment if not.

### Pod Security Policies
So, how do PSPs contribute to the security of your deployment? With PSPs you were able to define allowed values for the fields in the security context (and more, e.g. allowed volume types etc.). They act as an <a href="https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/" target="_blank">AdmissionController</a> and reject the creation of the Pod, if it does not comply with the range of allowed values defined in the PSP.

```yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: unprivileged-nonroot
  labels:
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
  readOnlyRootFilesystem: true
  runAsUser:
    rule: MustRunAsNonRoot
```

So far, PSPs do not look too bad, do they? Well... let’s get to the part that Tabitha Sable criticizes – how are PSPs applied to a Pod? Obviously, it is done via a ServiceAccount that is bound to a (Cluster)Role, which has the rights to use a certain PodSecurityPolicy. I do apologize for the sarcasm, but after the hard time I had understanding the concept and debugging PSPs / Pods, I felt like it was appropriate.

For example, the PodSecurityPolicy from above would be applied to a pod with these resources:
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-with-psp
—
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: unprivileged-nonroot
rules:
- apiGroups:
  - policy
  resources:
  - podsecuritypolicies
  resourceNames:
  - unprivileged-nonroot
  verbs:
  - use
—
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: 10-unpriviledged-clusterrole-assignment
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: unprivileged-nonroot
subjects:
- kind: ServiceAccount
  name: default
  namespace: sa-with-psp
—
apiVersion: v1
kind: Pod
metadata:
  name: debug
spec:
  serviceAccountName: sa-with-psp
  containers:
  -    image: nginx/nginx
    name: debug
```

## Gatekeeper to the rescue
Enough of the old stuff – PSPs were deprecated a long time ago, never left the beta phase and their EOL is approaching in big steps. Let’s focus on the alternatives.
In general, the approach of establishing some sort of admission controller works great for ensuring the usage of valid and pre-configured security measures.

### K8s internal PSP replacement – Pod Security Standards
The first alternative I want to present is the Kubernetes “native” concept of <a href="https://kubernetes.io/docs/concepts/security/pod-security-admission/" target="_blank">Pod Security Admission</a>. It provides the option to apply three provided <a href="https://kubernetes.io/docs/concepts/security/pod-security-standards/" target="_blank">Pod Security Standards</a>: baseline, privileged and restricted. These will be applied per namespace and will enforce one of the three named isolation levels.
Pod Security Standards and Admission provide a good and easier to use baseline to enforce pod security.

### Level-up using a fully fledged policy engine
Taking one step further, to achieve a more powerful and in-depth controlled pod security, you will come across a policy engine like <a href="https://www.openpolicyagent.org/" target="_blank">Open Policy Agent</a> (short: OPA) or <a href="https://kyverno.io/" target="_blank">Kyverno</a> rather soon. Generally, both are comparable. I will focus on presenting OPA (or rather <a href="https://open-policy-agent.github.io/gatekeeper/website/docs/" target="_blank">Gatekeeper</a>, but we’ll come to that in a second) in this post, as it was our go-to replacement for PSPs.

If you have never heard of the Open Policy Agent at all, I’d recommend reading my colleague Marco's <a href="/en/knowledge-hub/blog/open-policy-agent-primer-and-sample" target="_blank">blog post</a>. There you will get a decent overview of what the Open Policy Agent is all about and get to know another use case.

This blog post will focus on Gatekeeper. It acts as (not only) an AdmissionController in the form of validating (and/or mutating) webhooks enforcing all kinds of policies using OPA as its underlying policy engine. With Gatekeeper in place, you are able to make sure that your resources comply with your policies, before they are stored in etcd (and with that applied to your Kubernetes cluster). To represent your policies in the cluster, the concept relies on CustomResourceDefinitions (short: CRDs) – Constraints and ConstraintTemplates, but more on that later on.

The following facts are important to understand (in order to really get the huge benefit of using a policy engine-based solution like OPA Gatekeeper): 

1. The check is done based on a so-called <a href="https://pkg.go.dev/k8s.io/kubernetes/pkg/apis/admission#AdmissionRequest" target="_blank">admission request</a>, which contains – besides some metadata about the request – the actual manifest of the object in question in yaml or json format (the document).
2. OPA is domain-agnostic. It can be used on arbitrarily structured data. To put it in very simplified terms, with a policy you define which values should be allowed at any given path in the document.

Coming back to the main idea behind this blog post: securing your workloads. With Gatekeeper in place, you can create and apply several constraints in your cluster that will enforce the same set of requirements as PSPs do. To get started without diving too deep into <a href="https://www.openpolicyagent.org/docs/latest/policy-language/" target="_blank">Rego</a> (the language of OPA policies) you can use this <a href="https://github.com/open-policy-agent/gatekeeper-library/tree/master/library" target="_blank">library of constraints and templates</a>. This library contains templates to cover everything you previously did (or did not) via PSPs. Additionally, you can find inspiration and templates for lots of other use cases of Gatekeeper: check for duplicate hosts in ingresses, enforce sets of labels, create an allowlist for image-registries and many more.

### Apply Gatekeeper constraints in your cluster
As mentioned earlier in this blog post, Gatekeeper is based on CRDs.
At first, you create a constraint template (kind: ConstraintTemplate in templates.gatekeeper.sh) that contains your policy-logic and possible inputs.

```yaml
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8spspreadonlyrootfilesystem
  annotations:
    metadata.gatekeeper.sh/title: "Read Only Root Filesystem"
    description: >-
      Requires the use of a read-only root file system by pod containers.
      Corresponds to the `readOnlyRootFilesystem` field in a
      PodSecurityPolicy. For more information, see
      https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems
spec:
  crd:
    spec:
      names:
        kind: K8sPSPReadOnlyRootFilesystem
      validation:
        openAPIV3Schema:
          type: object
          description: >-
            Requires the use of a read-only root file system by pod containers.
          properties:
            exemptImages:
              description: >-
                Any container that uses an image that matches an entry in this list will be excluded
                from enforcement. Prefix-matching can be signified with `*`. For example: `my-image-*`.
              type: array
              items:
                type: string
  targets:
  - target: admission.k8s.gatekeeper.sh
    rego: |
      package k8spspreadonlyrootfilesystem
        
      violation[{"msg": msg, "details": {}}] {
        c := input_containers[_]
        input_read_only_root_fs(c)
        msg := sprintf("only read-only root filesystem container is allowed: %v", [c.name])
      }
      input_read_only_root_fs(c) {
        not has_field(c, "securityContext")
      }
      input_read_only_root_fs(c) {
        not c.securityContext.readOnlyRootFilesystem == true
      }
        
      input_containers[c] {
        c := input.review.object.spec.containers[_]
      }
      input_containers[c] {
        c := input.review.object.spec.initContainers[_]
      }
      input_containers[c] {
        c := input.review.object.spec.ephemeralContainers[_]
      }
        
      has_field(object, field) = true {
        object[field]
      }
```

To actually enforce the constraint, you need to instantiate the template. To do that, you create a constraint from the kind K8sPSPReadOnlyRootFilesystem (as defined in your template, l. 16) in the api-group constraints.gatekeeper.sh.

```yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPReadOnlyRootFilesystem
metadata:
  name: psp-readonlyrootfilesystem
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - “restricted”
  parameters:
    exemptImages:
      - "my-image-*"
```

This constraint for example would require pods in the namespace "restricted" to run with a read-only root file system – if the configured image does not start with "my-image-". While the `exemptImage` limitation is a user-defined setting in the template (<a href="https://github.com/open-policy-agent/gatekeeper-library/blob/master/library/pod-security-policy/read-only-root-filesystem/template.yaml" target="_blank">here</a> you can see the full reference; the snippet above was redacted for better readability), the `match` is system-defined. You can limit the scope of your policies using certain matchers – based on name, kind, namespace or labels. How each matcher works is best explained in the <a href="https://open-policy-agent.github.io/gatekeeper/website/docs/howto/#the-match-field" target="_blank">official gatekeeper-documentation</a>.
Using these matchers, you can selectively apply your constraints to certain parts of your cluster. Most likely, you will exclude namespaces like `kube-system`, as pods in them often need more privileges to fulfill their purpose.

## Conclusion
I hope this blog post encourages you to dig deeper into securing workloads in Kubernetes. Particularly concerning distributed and containerized systems like Kubernetes it is a very important topic, which is however often not considered early enough – or even not at all. Running Gatekeeper in a dry-run mode might be a good place to start, as it does not interrupt your service but gives you a first insight on what you could tackle in terms of k8s security. If you are interested, I will provide a follow-up post on how to visualize violations in your cluster easily.

One last thing to keep in mind – usage of Gatekeeper or Kyverno etc. does not automatically imply a secure workload. They only enforce the users of your cluster to make use of built-in security features as presented in this blog post. To achieve an in-depth runtime-security, you could check tools like <a href="https://github.com/falcosecurity/falco" target="_blank">falco</a>.

Secure your Kubernetes workloads with OPA Gatekeeper

**How to keep your IT infrastructure up to date and reduce manual effort to a minimum by using Kubernetes, Helm, GitOps (FluxCD), Continuous Integration (GitLab-CI) and Renovate.**

When we moved into our house, everything was new and shiny. Well – it was new and shiny because we had put a lot of effort and money into making it so. But just a few weeks after we moved in, the first scratches and flaws appeared. Having kids only accelerated this slow process of decay – and I (Daniel) have three of them. Oh, how I would have loved to see someone walking through the house regularly, noting everything that had to be renewed and taking care of it (well, someone that wasn't me). But everyone owning a house knows: you're never done. There is always something to do. And it will cost you time, effort and money to keep your house in good shape.

IT infrastructures and software systems are no different. Okay – you (hopefully) don't have kids jumping around in them, touching every white wall with their dirty hands, but the “best before” date of a lot of software components in your infrastructure will be passed rather soonish. In addition to that, there is a constant chance of burglars (hackers) breaking into it if you do not update the lock (authentication server) or windows every few weeks. But as opposed to poor me having no one else taking care of all the renovation work in my house, in IT infrastructures we can leverage automation to be our faithful janitor. I would like to show you how we implemented this and reduced our manual renovation efforts to a minimum by using Kubernetes, Helm, GitOps (FluxCD), Continuous Integration (GitLab-CI) and Renovate.

## Kubernetes
No matter if you are a fan of Kubernetes <a href="https://www.lastweekinaws.com/blog/a-brief-history-of-kubernetes-its-use-cases-and-its-problems/" target="_blank">or not</a>, it has become the de facto standard for hosting scalable multi-container environments. I completely agree that Kubernetes is used for a lot of use cases where it should not be used and other methods (some more traditional, some not) would have been a quicker, less complex and more efficient solution. However, once you have mastered the steep learning curve, Kubernetes and the <a href="https://landscape.cncf.io/" target="_blank">cloud-native landscape</a> have a lot of features, software projects and automations in the offering that can be used to make your day-to-day work a lot less tedious. No more forgotten certificate renewals with <a href="https://cert-manager.io/" target="_blank">cert-manager</a>, readily available monitoring and metrics with <a href="https://prometheus.io/" target="_blank">Prometheus</a>, log aggregation with <a href="https://grafana.com/oss/loki/" target="_blank">Grafana Loki</a> – just to name a few. A huge set of tools ready and waiting to help you manage your scaling infrastructure and application needs. And all those shiny new tools can be installed with the cloud-native package manager: <a href="https://helm.sh/" target="_blank">Helm</a>. 

## Helm
Just like your beloved package managers for DEB, RPM or AUR packages, Helm is the package manager for Kubernetes. Most of the software tools that can be deployed to Kubernetes have Helm charts available that abstract and automate the installation process for you. Each Helm chart packages a single application that can be deployed and configured by just providing the chart, chart version, and a values file that customizes your application deployment according to your needs.

## GitOps
<figure>
  <blockquote>
“GitOps is the best thing since configuration as code.”   
 </blockquote>
  <figcaption>— <a href="https://twitter.com/kelseyhightower/status/1164192321891528704" target="_blank">@kelseyhightower</a>
</figcaption>
</figure>

But what is it? GitOps is a declarative way of describing what components should be deployed to your infrastructure and how they should be configured. A good overview of what GitOps is, how it works and how you can get started with it has been provided by my colleague Daniel Henneberg <a href="/en/knowledge-hub/blog/gitops-argocd">here</a>. In short: a GitOps tool (like Flux) is an agent that runs within your target infrastructure and that fetches your infrastructure or configuration as code definitions from a Git repository as its single source of truth. In a reconciliation loop, the GitOps agent checks if either the code fetched from Git or your infrastructure changed, and it (re-)applies the desired state found in the code to your system.
This way you can:
Review changes in merge requests upfront.
Reduce error-prone manual interactions.
Automate the tedious task of manual deployments.
Have a versioned view and history of the changes made to your system.

## Renovate – the faithful janitor

Having all the tools and concepts above in place is like having a garage full of material and equipment. It’s essential to have, but someone needs to actually use it. Otherwise, it will just pile up and once in a while, you will need a complete makeover of your house. Someone needs to regularly check what has to be done and (ideally) do it without you noticing: enter the faithful janitor. Coming back to IT infrastructures and software systems, our janitor is the open-source software <a href="https://github.com/renovatebot/renovate" target="_blank">Renovate</a> and it comes for free.

Renovate can be used in multiple ways and on a decent number of platforms. In our case, Renovate runs as a scheduled Gitlab-CI job. Alternatively, you can use Renovate as GitHub Action or even as a (self-hosted) stateful application. When Renovate looks at a Git repository, it discovers what technologies and tools are used in the code and makes proposals on what to update. In each iteration it will automatically discover and (if configured) onboard new repositories, check for updated libraries and dependencies in them, open merge requests with the new versions and even merge them directly if you want it to.
Renovate does all that in a fully configurable way – you decide how it should behave to fit your needs. To be frank, the configuration is sort of overwhelming at the beginning. But once you get the idea, you will experience lots of “wow, even that can be done with Renovate” moments.
Renovate is not limited to the cloud-native world with containers and charts. It works with a <a href="https://docs.renovatebot.com/modules/manager/#supported-managers" target="_blank">huge number of package managers</a>, e.g. with pip, npm, maven and gomod, to just state a very small selection.

In our case, Renovate takes care of updating all our installed Helm charts. When Renovate initially onboarded our repository, it created a Gitlab Issue called “Dependency Dashboard”. This issue lists all detected dependencies, open or blocked MRs and potential problems. Since the onboarding, Renovate checks every hour (through a scheduled CI/CD pipeline) if new versions of the charts we use are available and if so, it creates new merge requests. Previously created merge requests by Renovate will be rebased and kept up to date if yet another new version is available before the old one was applied. Minor and patch releases will automatically be merged into the branch tracked by FluxCD and applied immediately to our staging environments. Some of our production systems cannot be updated during the working hours because it would cause an interruption of service. For those, Renovate will only create the MR enriched with release notes retrieved from the chart’s source (mostly GitHub).
In one of our setups, we install the same application multiple times in the cluster. Another handy Renovate feature: you can decide whether to update all instances at once (in a single merge request) or if you want to update them one by one.

## Applying updates with Renovate and Flux

![Renovate Workflow - Renovate Workflow.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/SabNtAebTGGJpUYvZiEW)

But how does our faithful janitor do its job? How do we get the new and shiny versions of the software applied to our systems? First of all, Renovate needs to check what software we use. Therefore it checks out our Git repository (1) and reads a <a href="https://docs.renovatebot.com/configuration-options/" target="_blank">`renovate.json`</a> file in the root folder. This file represents Renovate's configuration for our repository and we can configure what Renovate should and should not do with it. Renovate then continues to discover what dependencies it can find in the repository and which version of the respective dependency is currently in use. With this knowledge, Renovate can then check (2) if there are newer versions available by looking up the project sources of the used dependencies on the respective upstreams. If Renovate finds that a newer version is available, it will open a merge request (3) for our project repository with the updated version numbers. 
Now this is what we wished for, right? A list of things that are to do, well compiled by our faithful janitor, and a sophisticated proposal of how to do them. Now it is up to us to decide what should be done, and if we might want to change the color of the tiles (adapt the configuration) while we are renovating the bathroom (some software). As the operator we now want to carefully read through those proposals (merge requests) and modify or adapt configurations to fit the new versions requirements. Finally we can then merge (4) the merge request and define the new software version as the version we want to have deployed to our system. This is when Flux takes over. In its reconciliation loop, Flux regularly checks for changes in the code (5) and tries to apply the state declared in the code towards our system. Due to the changes we just made by accepting a merge request, it will recognize a difference between the current state in the system and the declared state in code and act accordingly to update the software on the system.

## Conclusion

By leveraging automation on both sides of the update process, i.e. sourcing in the updated software artifacts and rolling them out to the target system, we reduced our manual interaction for software system maintenance work to a bare minimum. Yet we keep full sovereignty over the updated chain by being able to accept, postpone or reject merge requests as we want. Our faithful janitor gathers and presents all the maintenance work in separate chunks and provides us with ready-to-use plans for the execution.
Unfortunately this free-of-charge renovation full service is only available for software systems, not for our real-world houses. What a shame!  

Time to Renovate

Service Lead GitLab Solutions

Wissen tanken!

Hier anmelden

Wir sind vor Ort und stehen dir gerne für all deine Fragen zur Verfügung.

Sei dabei!

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digitale Produkte & Lösungen

Digitale Souveränität

IT-Security

Künstliche Intelligenz

Software-Modernisierung

Leistungen von A bis Z ...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Deine Entwicklung

Jobs

Kultur & Karriere Podcast

Unsere Kultur

Karriere

Über uns

Aktuelles

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

GitLab DACH Roadshow 2025 | Düsseldorf

Sei dabei!

Wissen tanken!

Noch Fragen?

Jetzt für unseren Newsletter anmelden