GitLab DACH Roadshow 2024 | 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="https://blog.codecentric.de/2010/10/javaone-2010/"><img src="https://media.graphassets.com/ayOlAHwoSseoj5HgNluO" alt width="540" height="404" /></a> </p><p>Wie schon im Vorjahr waren <a href="http://blog.codecentric.de/en/2009/06/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://media.graphassets.com/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://media.graphassets.com/ep6aWMMeScmjrmEY1arF" alt width="540" height="405" /><img loading="lazy" src="https://media.graphassets.com/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

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 2024 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="https://blog.codecentric.de/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="https://blog.codecentric.de/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://media.graphassets.com/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

Head of GitLab Solutions

<p>Bei klassischen Machine-Learning-(ML-)Projekten beschäftigen sich Data Scientists häufig längere Zeit (<strong>mehrere Monate</strong>) mit der Entwicklung eines ML-Modells. Dabei werden hohe Kosten verursacht und die Zeit, bis ein erstes Modell zur Verfügung steht, ist verhältnismäßig lang. Hinzu kommt die Zeit, bis das Modell in der Produktion eingesetzt wird. Zu diesem Zeitpunkt weiß man auch noch nicht, ob sich ein ML-Ansatz überhaupt für den vorliegenden Use Case eignet.</p><p>Hier kann der Service AutoML (<strong>Auto</strong>mated <strong>M</strong>achine <strong>L</strong>earning) der Google Cloud Platform (GCP) verwendet werden. AutoML (siehe auch <a href="https://blog.codecentric.de/2020/07/ki-in-der-praxis-fehlerhafte-bauteile-mit-automl-in-der-google-cloud-identifizieren/">diesen Blogpost</a> ) eignet sich somit, wenn sich ein Betrieb einen Vorteil von der Benutzung von Machine Learning verspricht, aber noch keine bis wenige Berührungspunkte damit hatte. Mit AutoML kann zügig (<strong>in wenigen Wochen</strong>) und ohne viel Vorwissen ein erster Prototyp entwickelt werden. Dies wollen wir im Folgenden anhand eines Anwendungsbeispiels vorstellen.</p><h2>Use Case: Qualitätskontrolle in der Verpackungsindustrie</h2><p>Wir haben uns mit der automatischen Qualitätskontrolle in der industriellen Fertigung beschäftigt. Ziel war es, für einen Kunden einen ML-Prototyp zu entwerfen. Dieser sollte in  die bestehende Fließbandproduktion integriert werden und beschädigte Verpackungen erkennen, um diese auszusortieren. Als Grundlage hat der Kunde uns ca. <strong>50.000 gelabelte Bilder</strong> zur Verfügung gestellt, wovon wir ca. die Hälfte für das Training verwendet haben. Da es sich bei unserer Problemstellung um eine binäre Klassifikation handelt, wurden die Bilder in <strong>correct</strong> und <strong>damaged</strong> unterteilt. Bedingt durch den Einsatz am Fließband gab es zusätzlich die Anforderung, dass die Klassifizierung und Übertragung <strong>nicht länger als 600 ms</strong> in Anspruch nehmen dürfen. Folgend sieht man eine symbolhafte Darstellung des Use Cases.</p><div><img src="https://media.graphassets.com/fshLzq6sSymZJigDlsQI" alt="Symbolhafte Darstellung des Use Cases" width="279" height="339" /><p>Quelle: Denis Stalz-John</p></div><h2>Umsetzung auf der Google Cloud mit AutoML Vision</h2><p>Die Google Cloud Platform (GCP) bietet eine Vielzahl von Cloud-Computing-Services an. Hierzu zählen beispielsweise Datenbanklösungen, Infrastruktur-Modernisierung und AI- & ML-Services. Zum Zeitpunkt der Veröffentlichung dieses Blogposts bietet Google zudem <a href="https://cloud.google.com/free" target="_blank">300 $ Free Credits</a>  an.</p><p><span>In der GCP haben wir folgende Schritte ausgeführt:</span></p><ul><li>Daten-Upload</li><li>Daten-Labeling</li><li>Modell-Training</li><li>Modell-Validierung</li><li>Deployment</li></ul><p>Für AutoML und <a href="https://cloud.google.com/ai-platform" target="_blank">AI Platform (Unified)</a>  gibt es eine Weboberfläche, die die oben genannten Schritte ermöglicht. Folgend wird die AI Platform (Unified) mit einem einfachen Beispiel gezeigt, wobei die gezeigten Teile sehr ähnlich zu dem Gegenstück von AutoML sind. Sobald man ein Google-Cloud-Projekt erstellt hat und zu der AI Platform (Unified) navigiert, sieht man folgendes Bild. Um nun ein Modell zu erstellen, wird zunächst ein Datensatz erstellt.</p><div><a href="https://media.graphassets.com/gXZkF1AIRmGYewtgZJUR"><img loading="lazy" src="https://media.graphassets.com/gXZkF1AIRmGYewtgZJUR" alt="Startseite der AI Platform (Unified)" width="1898" height="912" /></a> <p>Startseite der AI Platform (Unified)</p></div><h3>Daten-Upload</h3><p>Für diesen Datensatz werden Bilder benötigt, die man ganz einfach über den Browser hochladen kann.</p><div><a href="https://media.graphassets.com/FtvJlVvTSvCKN6dVghUP"><img loading="lazy" src="https://media.graphassets.com/FtvJlVvTSvCKN6dVghUP" alt="Bilder import Tab der GCP" width="963" height="541" /></a> <p>Daten Upload</p></div><p>Sobald Bilder von der lokalen Festplatte ausgewählt wurden, werden sie hochgeladen und in der Oberfläche angezeigt. Beim Hochladen wird automatisch ein Cloud Storage Bucket erstellt, der unten in der Oberfläche benannt werden kann, bevor man den Datensatz erstellt. Leider können über die AutoML-Oberfläche zum Zeitpunkt der Veröffentlichung dieses Posts nur 500 Bilder auf einmal hochgeladen werden. Um dieses Problem zu umgehen, können Bilder direkt in einen Cloud Storage Bucket hochgeladen werden. Bei dieser Möglichkeit muss der GCP-Nutzer allerdings selber eine CSV-Datei erstellen, die die Bilder in Klassen aufteilt. Diese Datei wird dann in Verbindung mit dem GCS Bucket von AutoML genutzt, um den Datensatz zu erstellen.</p><div><a href="https://media.graphassets.com/XK8Pjd7ET3eg7o2Opda4"><img loading="lazy" src="https://media.graphassets.com/XK8Pjd7ET3eg7o2Opda4" alt="Bilder upload der GCP" width="1274" height="853" /></a> <p>Daten Upload</p></div><h3>Daten-Labeling</h3><p>Sofern die Bilder wie hier gezeigt über die UI hochgeladen werden, müssen diese danach noch gelabelt werden. Um dies zu erreichen, wird ein neues Label erstellt und auf alle neuen Bilder angewendet. Eine weitere Möglichkeit ist es, die Bilder mit einer CSV-Datei aus einem Google Cloud Storage Bucket in den Datensatz zu laden und automatisch in Klassen aufzuteilen.</p><div><a href="https://media.graphassets.com/GRvQKhzQLSpy8SPhoxb7"><img loading="lazy" src="https://media.graphassets.com/GRvQKhzQLSpy8SPhoxb7" alt="Bilder labeln in der GCP" width="1920" height="868" /></a> <p>Daten-Labeling</p></div><h3>Modell-Training</h3><p>Der vorherige Schritt wird nun für jede Bildklasse wiederholt; sobald sich alle Daten im Datensatz befinden, kann das Training gestartet werden.</p><div><a href="https://media.graphassets.com/Bj2e6ZHfRX6NMcYc7gua"><img loading="lazy" src="https://media.graphassets.com/Bj2e6ZHfRX6NMcYc7gua" alt="Budget festlegen" width="848" height="369" /></a> <p>Modell-Training</p></div><p>Ein <a href="https://cloud.google.com/ai-platform-unified/pricing" target="_blank">Budget</a>  (<strong>node hours</strong>) wird für das Training, das bei unseren Tests zwischen <strong>4 und 12 Stunden</strong> gedauert hat, festgelegt. Nach Abschluss stellt Google in der GCP eine Analyse des produzierten Modells zur Verfügung. Diese Analyse beinhaltet verschiedene in der Deep-Learning-Umgebung übliche Metriken, um ein Modell zu evaluieren.</p><h3>Modell-Validierung</h3><div><a href="https://media.graphassets.com/1aie6CeLQKi1uYCCPlL8"><img loading="lazy" src="https://media.graphassets.com/1aie6CeLQKi1uYCCPlL8" alt="GCP Evaluations Tab" width="1294" height="721" /></a> <p>Modell-Validierung</p></div><p>In dem oben zu sehenden <em>Evaluate</em>-Tab wird die Analyse des Modells angezeigt. Hier werden verschiedene <a href="https://cloud.google.com/vision/automl/docs/beginners-guide#evaluate">Metriken</a>  zur Verfügung gestellt, um die Qualität des Modells zu bewerten. Über den Confidence Threshold kann man einstellen, wie sicher sich das Modell sein muss, um ein Bild einer Klasse zuzuordnen. Im gezeigten Beispiel muss sich das Modell zu mindestens 50 % sicher sein, um ein Bild als <em>correct</em> zu klassifizieren.</p><h3>Deployment</h3><p>Dieses Modell kann in der GCP deployt werden oder eine Modell-Datei kann in fünf verschieden Formaten heruntergeladen werden. Der Vorteil des lokalen Hostings liegt bei niedrigeren Latenzen, was für eine schnelle und effiziente Fließbandproduktion essenziell ist. Außerdem fallen keine laufenden Kosten innerhalb der GCP für den Kunden an.</p><div><a href="https://media.graphassets.com/NiBgAw6ZT4FmiB6ixhUs"><img loading="lazy" src="https://media.graphassets.com/NiBgAw6ZT4FmiB6ixhUs" alt="Export Optionen des Modells" width="1281" height="222" /></a> <p>Export Optionen</p></div><p><b>Disclaimer:</b> Zu Beginn des Projekts war AutoML noch ein alleinstehendes Produkt in der GCP. Mittlerweile ist AutoML jedoch Teil der <b>AI Platform (Unified)</b> auf der GCP. Die hier gezeigten Screenshots entstammen der Variante auf der AI Platform (Unified), jedoch sollte es keine großen Unterschiede bei den gezeigten Schritten geben.</p><h2>Unblackboxing mit Explainable AI</h2><p>Ein Nachteil von AutoML ist, dass das erzeugte Modell eine <strong>Black Box</strong> ist und somit auch nicht erweiterbar oder modifizierbar ist. Als Nutzer muss man Google vertrauen, dass bspw. die besten Hyperparameter gewählt werden. Allerdings kann es durch Explainable AI besser verstanden werden.</p><p>In unserem Use Case möchte man eine visuelle Begründung der Vorhersage erhalten. Es wäre also wünschenswert zu wissen, welche Pixel auf dem Bild jeweils für oder gegen spezifische Klassifizierungen sprechen. Ist bspw. der Bildhintergrund ausschlaggebend für die Entscheidung?</p><h2>Fazit</h2><p>Abschließend können wir sagen, dass AutoML mit der AI Platform (Unified) dabei unterstützen kann, einen Prototyp eines Machine-Learning-Modells in sehr kurzer Zeit, mit begrenzten Ressourcen und ohne Expertenwissen zu erstellen. Somit kann ein ML Use Case schnell validiert werden. Die Weboberfläche ist benutzerfreundlich sowie minimalistisch und übersichtlich gestaltet. Einziger Nachteil: Zum aktuellen Zeitpunkt hat AutoML eher Black-Box-Charakter, der jedoch kontinuierlich mit neuen <a href="https://cloud.google.com/explainable-ai" target="_blank">Explainable-AI-Services</a>  abgeschwächt wird.</p><p>Give it a try.</p><p><strong>Ressourcen</strong></p><p> </p><ul><li><a href="https://cloud.google.com/free" target="_blank">GCP Free Credits</a> </li><li><a href="https://cloud.google.com/ai-platform" target="_blank">AI Platform Unified</a> </li><li><a href="https://cloud.google.com/ai-platform-unified/pricing" target="_blank">AI Platform (Unified) Pricing</a> </li><li><a href="https://cloud.google.com/vision/automl/docs/beginners-guide#evaluate" target="_blank">Google AutoML Vision Evaluation</a> </li><li><a href="https://cloud.google.com/explainable-ai" target="_blank">Google Explainable AI</a> </li></ul><p> </p><p> </p><p><a href="https://www.codecentric.de/karriere/jobs/cloud-native-entwicklerin?utm_campaign=PeSo%20Blog%20to%20Job&utm_source=cc_blog&utm_medium=display&utm_content=cloud_native_developer_und_consultant" target="_blank"><img loading="lazy" width="660" height="220" src="https://media.graphassets.com/j6Fy55RIRSO26P6MzSrX" alt="Mitglieder für unsere Gilde gesucht! Jetzt der Gilde als Cloud Native Developer und Consultant (w/d/m) beitreten" /></a> </p><p> </p><p> </p>

Schnelles KI-Prototyping mit Google Cloud AutoML Vision

Die Migration in die Cloud bringt einige Herausforderungen mit sich. Viele Unternehmen stehen vor der Frage, wie ein effizienter und sicherer Aufbau einer skalierbaren Cloud-Infrastruktur umzusetzen ist. Die Antwort auf diese Herausforderung liegt in der Verwendung von Azure Landing Zones – einem hilfreichen Ansatz, der den Migrationsprozess reibungsloser gestalten kann. In diesem Kontext stolpern Unternehmen immer wieder über folgende Fragen:

### Wie organisiere ich meine Subscriptions?
Der Aufbau einer Cloud-Infrastruktur beginnt mit der richtigen Strukturierung von Subscriptions. Hierbei stehen Unternehmen oft vor dem Dilemma, ihre Subscriptions so zu konfigurieren, dass verschiedene Workloads reibungslos unterstützt werden. Mangelnde Standardisierung und unzureichende Skalierbarkeit führen häufig zu ineffizienten Prozessen und somit zu unnötigen Kosten.

### Wie erreiche ich einen hohen Automatisierungsgrad der Cloud-Ressourcen? 
Von einer Cloud-Nutzung versprechen sich Unternehmen Effizienz und Agilität. Manuelle Prozesse bei der Bereitstellung und Verwaltung von Cloud-Ressourcen können diese Vorteile schmälern. Ein hoher Automatisierungsgrad  ist ein entscheidender Faktor, um das volle Potenzial der Cloud nutzen zu können. 

### Wie können Best Practices erfolgreich implementiert werden?
Unternehmen stehen vor der Herausforderung, bewährte Methoden, klare Leitlinien und Best Practices zu finden, die ihnen helfen, eine solide Basis für ihre Cloud-Infrastruktur zu schaffen. Fehlendes Know-How in diesen Bereichen kann dazu führen, dass zeitintensive Einarbeitung die Cloud-Migration ausbremst.

In den kommenden Abschnitten werden wir diese Herausforderungen beleuchten und zeigen, welche Vorteile Azure Landing Zones mit sich bringen. 

## Was sind eigentlich Azure Landing Zones?
Azure Landing Zones sind ein Konzept, das sich auf die Architektur und Implementierung der grundlegenden Cloud-Ressourcen konzentriert. Hierbei können sich Unternehmen an klaren Strukturen orientieren, um eine initiale Cloud-Umgebung zu erstellen. Dabei unterstützen Landing Zones, die Workloads in die Cloud zu migrieren, indem sie Best Practices und bewährte Pattern für Netzwerkarchitektur, Identitätsmanagement, Ressourcenorganisation und Governance bereitstellen.

### Welche Vorteile bringen Azure Landing Zones mit?
Landing Zones ermöglichen eine schnellere und effizientere Migration, indem organisationsweit konsistente Architekturen gefördert und der Einsatz bewährter Methoden erleichtert werden. Folgende Vorteile bringt die Verwendung von Landing Zones mit sich:

**Konsistente Architektur:**
Azure Landing Zones bieten eine klare und standardisierte Architektur für den Aufbau der Cloud-Infrastruktur. Dies gewährleistet eine einheitliche Umsetzung bewährter Praktiken, die die Basis für eine erfolgreiche Cloud-Migration bilden.

**Zeitersparnis:**
 Durch die Verwendung von vorkonfigurierten Architekturmustern muss die initiale Grundstruktur der Organisation nicht von Grund auf neu geplant werden. 

**Sicherheit:**
 Azure Landing Zones sind darauf ausgerichtet, Best Practices zu berücksichtigen. Durch die Implementierung dieser ist ein Mindestmaß an Sicherheit garantiert.

**Kosteneffizienz:**
 Eine gut durchdachte Cloud-Architektur kann dazu beitragen, unnötige Kosten zu vermeiden und die Ressourcennutzung zu optimieren. Azure Landing Zones unterstützen Unternehmen dabei, Kostenfallen zu vermeiden und ihre Cloud-Ressourcen effizient zu verwalten.

**Automatisierung und Skalierbarkeit:**
Azure Landing Zones ermöglichen einen hohen Automatisierungsgrad der Ressourcenbereitstellungen. Dadurch können Unternehmen ihre Cloud-Infrastruktur einfacher skalieren und sich auf ihr Kerngeschäft konzentrieren.

**Governance und Kontrolle:** Durch die Implementierung von Governance-Mechanismen können Unternehmen die Verwaltung und Kontrolle ihrer Cloud-Ressourcen verbessern. Dies umfasst die Verwaltung von Zugriffsrechten, Richtlinien, Compliance-Vorgaben und Kostenkontrollen.

### Kernkomponenten einer Landing Zone
Doch wie sieht eine solche konkrete Architekturvorlage nun aus? Je nach Use Case und Größe der Organisation können Landing Zones in ihrer Komplexität unterschiedlich ausgeprägt sein. Die Kernkomponenten stellen dabei jedoch immer die Plattform- und Application Landing Zones dar.

Unter einer **Plattform-Landing-Zone** (siehe Identity-, Management- und Connectivity-Subscription) versteht man eine Subscription, die Cloud-Ressourcen zur Verfügung stellt, welche von den anderen Landing Zones verwendet werden. Beispiele hierfür sind eine geteilte Netzwerkinfrastruktur und Logging. Die Nutzung von geteilten Ressourcen verringert den Konfigurationsaufwand und ermöglicht dadurch eine höhere Skalierbarkeit sowie die einfache Erweiterung der Cloud-Umgebung durch bspw. eine adaptive Integration von Subscriptions.

Eine **Application-Landing-Zone** (siehe Punkt F, Landing Zone A2 subscription) hingegen ist eine Subscription, in der die eigentliche Anwendung betrieben wird. In dieser Architektur werden Ressourcen mit Hilfe von Management Groups, Subscriptions und Resource Groups in eine vorgegebene Hierarchie integriert, um einzelne Anwendungen organisatorisch voneinander zu trennen. Application-Landing-Zones können die Ressourcen der Plattform-Landing-Zones verwenden. 

![ns-arch-cust-expanded.svg](https://media.graphassets.com/45zYzQiFSm2BEP3N7sAN)
Quelle: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/

### Deploymentoptionen
Es gibt diverse Optionen, Azure Landing Zones umzusetzen – Azure-Portal-basiert oder mittels Infrastructure-as-Code mit Terraform oder Bicep. Eine einfache Möglichkeit, schnell die Landing-Zones-Grundstruktur aufzubauen, ist beispielsweise die Nutzung des offiziellen [Azure-Landing-Zone-Moduls](https://registry.terraform.io/modules/Azure/caf-enterprise-scale/azurerm/latest) für Terraform. Das Modul bietet eine Vielzahl an Konfigurationsmöglichkeiten – von einer initialen Standard-Grundstruktur bis hin zu einer vollständig auf das Unternehmen angepassten Implementierung.

### Anpassungsmöglichkeiten

Neben den vordefinierten Best Practices können Anpassungen an die Organisationsstruktur und den deployten Ressourcen vorgenommen werden. Daher lohnt es sich zu prüfen, ob für die zu erwartenden Use Cases zusätzliche Konfigurationen durchgeführt werden sollten. Aus Compliance-Gründen kann es notwendig sein, weitere Richtlinien für Management Groups zu definieren, wie etwa die erlaubten Regionen für Ressourcen einzuschränken. Ebenso können die geteilten Ressourcen beispielsweise um eine globale DNS-Zone erweitert oder Budget-Alarme eingerichtet werden, um unerwartete Kosten rechtzeitig zu detektieren.

## Fazit
Azure Landing Zones bieten Unternehmen eine effiziente Möglichkeit, die Time-To-Market zu reduzieren und sich auf ihr Kerngeschäft zu konzentrieren, während sie von standardisierten Governance- und Sicherheitsstrukturen profitieren. Durch die Vereinfachung von Managementaufgaben können Unternehmen die Komplexität verringern und ihre Cloud-Infrastruktur auf einem zuverlässigen Fundament aufbauen. 


Mehr Struktur in der Cloud mit Azure Landing Zones

Disaster Recovery (DR) ist ein elementarer Bestandteil der IT-Sicherheit für Unternehmen. Ein DR-Plan hilft dabei, sich auf den Ausfall kritischer Systeme oder Infrastrukturen vorzubereiten und diese schnellstmöglich wiederherzustellen. In den nachfolgenden Abschnitten werden wir DR-Strategie-Ansätze aufzeigen – exemplarisch anhand von AWS Architekturbeispielen.

Vor allem im regulierten Umfeld ergeben sich besondere Anforderungen an die Business Continuity Management (BCM)- und DR-Strategien. BCM ist ein essenzieller Aspekt für Unternehmen, um sicherzustellen, dass sie ihre Geschäftsprozesse auch unter extremen Bedingungen aufrechterhalten können. Regulierte Branchen wie Finanzdienstleister oder Versicherungen haben oftmals strikte BCM-Richtlinien. Diese ergeben sich u.a. aus gesetzlichen Vorgaben – ein Beispiel hierfür ist die Datenschutz-Grundverordnung oder die Versicherungsaufsichtlichen Anforderungen an die IT (VAIT). Die VAIT-Richtlinien wurden von der Bundesanstalt für Finanzdienstleistungsaufsicht eingeführt und legen spezifische Anforderungen an das IT-Risikomanagement und die IT-Governance für Versicherungsunternehmen fest. Die gesetzlichen Vorgaben umfassen u.a. die folgenden Bereiche:

**IT-Resilienz:** IT-Resilienz bezieht sich auf die Fähigkeit eines Unternehmens, Störungen, beispielsweise verursacht durch Cyberangriffe oder technische Ausfälle, zu bewältigen und den Geschäftsbetrieb zeitnah wieder aufzunehmen. Daher ist eine fundierte DR-Strategie von großer Bedeutung, um die fortlaufende Erbringung von Dienstleistungen zu gewährleisten.

**Schutz der Kundendaten:** Versicherungsunternehmen verarbeiten insbesondere sensible Kundendaten, wie personenbezogene Informationen, finanzielle Daten und Gesundheitsdaten. Eine DR-Strategie muss sicherstellen, dass diese Daten jederzeit verfügbar, geschützt und vor Datenverlust oder -manipulation bewahrt werden. 

**Geschäftskontinuität:** Kontinuität von Geschäftsprozessen ist von großer Bedeutung, nicht nur für die Versicherungsbranche. Durch die Berücksichtigung von entsprechenden DR-Strategien können Versicherungsunternehmen sicherstellen, dass ihre Dienste auch während Ausfällen ununterbrochen laufen.
 
**Risikoabwägung:** Die Implementierung einer Disaster-Recovery-Strategie trägt dazu bei, bewusste Entscheidungen hinsichtlich verschiedener Ausfallszenarien zu treffen und auch zu dokumentieren. Hier findet eine Abwägung der Kosten der DR-Strategie gegenüber der Eintrittswahrscheinlichkeit des Ausfalls inkl. der daraus resultierenden Schäden statt. 

### Was ist eigentlich Disaster Recovery?

Disaster Recovery beschreibt die Planung und Implementierung von Maßnahmen zur Erreichung der IT-Resilienz. Ziel ist die schnellstmögliche Wiederaufnahme des Geschäftsbetriebs nach unvorhergesehenen Ereignissen wie bspw. Naturkatastrophen, menschlichem Versagen oder Cyberattacken. Eine gut durchdachte Disaster-Recovery-Strategie ist entscheidend, um Geschäftsunterbrechungen zu minimieren und das Vertrauen der Kunden aufrechtzuerhalten. Ein Disaster-Recovery-Plan beschreibt zwei zentrale Ziele:

**Recovery Time Objective (RTO):** Maximale Zeitspanne vom Beginn des Ausfalls bis zur Wiederherstellung des Geschäftsprozesses (Wie lange darf ein Geschäftsprozess ausfallen?).

**Recovery Point Objective (RPO):** Maximale Datenmenge, die verloren gehen darf (gemessen vom Zeitpunkt des Ausfalls bis zum Zeitpunkt der letzten Sicherung, die wiederhergestellt wird).

![rpo_rto(3).png](https://media.graphassets.com/cFwVRmzuQuSxOCTI3hQb)

### AWS Disaster-Recovery-Optionen
AWS bietet eine Vielzahl von DR-Optionen, die es Unternehmen ermöglichen, ihre Workloads in der Cloud zu schützen und eine hohe Verfügbarkeit zu gewährleisten. 

**Backup & Restore:** Diese einfache Methode beinhaltet das regelmäßige Sichern der Daten und Systeme in AWS. Im Notfall werden diese aus den aktuellsten Sicherungen wiederhergestellt. Obwohl einfach umzusetzen, kann diese Methode längere Ausfallzeiten mit sich bringen, da die Wiederherstellung möglicherweise einige Zeit in Anspruch nimmt. Diese Methode eignet sich somit für Systeme, die schnell wiederherzustellen sind oder bei denen längere Ausfallzeiten keine geschäftskritischen Auswirkungen verursachen. Die Infrastruktur läuft ausschließlich in einer primären Region. Die sekundäre Region wird nur für ein Cross-Region-Backup verwendet, nicht aber für redundante Infrastruktur-Komponenten.

![backup-restore-architecture.png](https://media.graphassets.com/FZhG7Bn7TfBN6wW1JAF1)
Quelle: <a href="https://aws.amazon.com/de/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/" target="_blank">AWS</a>

**Pilot Light:** Diese Strategie beinhaltet die ständige Replikation eines Teils der Produktionsumgebung in einer sekundären Region. Es laufen keine aktiven Geschäftsprozesse in dieser Umgebung. Sie steht lediglich bereit, um im Notfall schnell und effizient hochgefahren zu werden, so dass der Produktionsbetrieb in dieser Umgebung fortgeführt werden kann. Diese Methode eignet sich für Systeme, deren Wiederherstellung aus Sicherungen nicht-tolerierbare Ausfallzeiten verursachen, während gleichzeitig die benötigte Zeit zum Hochfahren der Umgebung tolerierbar ist.

![pilot-light-architecture.png](https://media.graphassets.com/qxTTWrSWOBP2pv7RkDew)
Quelle: <a href="https://aws.amazon.com/de/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/" target="_blank">AWS</a>

**Warm Standby:** Hierbei handelt es sich um eine erweiterte Version der Pilot-Light-Methode. Ein Teil der Produktionsumgebung wird in einer sekundären Region dauerhaft betrieben, um die Ausfallzeit zu minimieren und eine schnellere Wiederherstellung zu ermöglichen. Im Unterschied zur Pilot Light-Methode ist die Warm-Standby-Umgebung im Notfall sofort einsetzbar und muss nicht erst hochgefahren werden. Sie muss jedoch noch skaliert werden, um vergleichbare Leistungsmerkmale wie die ausgefallene Produktionsumgebung zu erreichen.

![warm-standby-architecture.png](https://media.graphassets.com/pjR2Zs8KS4S6DD4je46s)
Quelle: <a href="https://aws.amazon.com/de/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/" target="_blank">AWS</a>

**Active/Active:** Diese fortschrittliche Strategie verteilt den Datenverkehr und die Workloads auf mehrere AWS-Regionen. Da Infrastruktur, Anwendung und Daten synchronisiert werden, erhöht dies die Ausfallsicherheit. Bei einem Ausfall einer Region erfolgt der automatische Failover in eine andere Region nahezu in Echtzeit.

![multi-site-active-active-architecture.png](https://media.graphassets.com/pXmx2ul3T6S0zpO2ctuQ)
Quelle: <a href="https://aws.amazon.com/de/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/" target="_blank">AWS</a>

### Entscheidungshilfe
Bei der Auswahl der DR-Strategien spielen mehrere Faktoren eine Rolle, u. a. Kosten, Geschäftskritikalität und Wiederanlaufzeiten. Das Backup- & Restore-Verfahren ist vergleichsweise kostengünstig, da es keine zusätzlichen Ressourcen im Standby-Modus bereithält. Dafür ist es das Verfahren mit der vergleichsweise längsten Wiederanlaufzeit. Das Active/Active-Szenario besitzt die gegensätzlichen Eigenschaften. Es verursacht aufgrund des dauerhaft hohen Ressourcenbedarfs vergleichsweise hohe Kosten, kann dafür im Störungsfall nahezu unterbrechungsfrei weiterarbeiten.

Um die Anforderungen an den DR-Plan zu ermitteln, wird zunächst eine Business-Impact-Analyse durchgeführt. Die Business-Impact-Analyse betrachtet die Auswirkung von Störungen auf die Geschäftsprozesse einer Organisation. Dabei wird das Schadenspotenzial, das durch die Beeinträchtigung des regulären Geschäftsbetriebs entsteht, über einen Zeitverlauf ermittelt. Schäden können dabei beispielsweise durch Umsatzausfall, Verletzung regulatorischer Vorgaben oder auch in der öffentlichen Wahrnehmung der Organisation entstehen. Erzeugt der Ausfall eines Geschäftsprozesses nach Ablauf einer definierten Zeitspanne einen nicht-tolerierbaren Schaden, so muss die Organisation sicherstellen, dass die zugrundeliegenden Systeme und Ressourcen innerhalb dieser Zeitspanne wiederhergestellt werden können.

Die Auswahl der geeigneten Disaster-Recovery-Option sollte sich also aus den maximal tolerierbaren Systemausfallzeiten und Datenverlustmengen, die in der Business-Impact-Analyse ermittelt wurden, sowie der benötigten Wiederanlaufzeit der jeweiligen DR-Option ergeben. Die Wiederherstellung der Systeme muss dabei regelmäßig geprüft und getestet werden, um die kritischen Vorgaben der Organisation nicht zu gefährden.

Die nachfolgende Abbildung zeigt für die unterschiedlichen DR-Strategien die Faktoren Kosten und RTO/RPO auf. Hierbei bewegen sich RTO/RPO in den Bereichen von mehreren Stunden bis hin zu (fast) Echtzeit. Im Allgemeinen sind für das Active/Active-Szenario mindestens doppelt so hohe Kosten für die Infrastruktur im Vergleich zum Backup & Restore-Szenario zu erwarten, da die Ressourcen redundant betrieben werden.

![dr-strategien(9).png](https://media.graphassets.com/yoKSRJkTQr6N9ngWpOQ5)

### Fazit
AWS bietet Unternehmen unterschiedliche Ansätze für Disaster-Recovery-Strategien an. Diese unterscheiden sich vor allem bei den Aspekten RTO/RPO und den damit verbundenen Kosten für die Infrastruktur. Hierbei sollten Unternehmen immer das Kosten-Nutzen-Verhältnis der Strategie berücksichtigen. Die Investitionen in eine geeignete DR-Strategie ist somit nicht nur eine reine Vorsichtsmaßnahme, sondern im regulierten Umfeld auch zwingend erforderlich, um Geschäftskontinuität sicherzustellen.


Disaster-Recovery-Strategien in AWS

Cloud Consultant

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

Cloud-Native

Data & Machine Learning

Generative KI

Produktentwicklung

IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

International contact

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 2024 | Düsseldorf

Sei dabei!

Hier anmelden

Wissen tanken!

Noch Fragen?

Kontaktiere uns

Hier anmelden

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten