June 28, 2023(Rev: 2024-05-08)-
Thomas Jungbauer
-
3 min read(653 words)
Besides checking the source code quality, we should also verify if the commit into Git was done by someone/something we trust. It is a good practice to sign all commits to Git. You need to prepare your Git account and create trusted certificates.
I will not describe how exactly you need to configure Git to sign your commit. Verify the following link to learn more about Signing Commits
Goals
The goals of this step are:
Verify if the last commit has been signed
Prerequisites
Signing public key
Configured Git to verify your gpg signature
When your commit is signed, Git will show that:
Figure 1. Pipeline
Steps
Create the following Secret that contains your PUBLIC key.
kind: Secret
apiVersion: v1
metadata:
name: gpg-public-key
namespace: ci
data:
public.key: >-
<Base64 PUBLIC GPG KEY> (1)
type: Opaque
1
Public key, containing BEGIN/END lines base64 encoded.
Create the following Task:
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: verify-source-code-commit-signature
namespace: ci
spec:
description: This task verifies the latest commit and signature against the gpg
public key
params:
- default: 'registry.redhat.io/openshift-pipelines/pipelines-git-init-rhel8:v1.10.4-4'
name: gitInit
type: string
steps:
- computeResources: {}
image: $(params.gitInit)
name: git-verify
script: |
set -x (1)
gpg --import /workspace/secrets/public.key
git config --global --add safe.directory /workspace/repository
git verify-commit HEAD || (echo "Unable to verify commit at HEAD!" && exit 1)
workingDir: /workspace/repository
workspaces:
- name: repository
- name: secrets (2)
1
The script to verify the signature of the commit,
2
The workspace that mounts the Secret containing the gpg key,
Modify the TriggerTemplate and add the following 3 lines
Let’s update the README.md of our source code again to trigger another PipelineRun.
Now the 3rd task will verify if the commit was signed.
Figure 3. PipelineRun Details
In the logs of the Task, we can see that the commit was signed and could be verified.
See:
...
gpg: Good signature from "Thomas Jungbauer <tjungbau@redhat.com>"
...
Figure 4. Signature Verification
Summary
At this stage we have a Pipeline, that pulls our code, does a code analysis, and verifies if the commit has been signed.
The very next step is to build the image and push it into an Image Registry.
In the previous articles, we deployed a distributed tracing infrastructure with TempoStack and OpenTelemetry Collector. We also deployed a Grafana instance to visualize the traces. The configuration was done in a way that allows everybody to read the traces. Every system:authenticated user is able to read ALL traces. This is usually not what you want. You want to limit trace access to only the appropriate namespace.
In this article, we’ll limit the read access to traces. The users of the team-a namespace will only be able to see their own traces.
While we have been using the integrated tracing UI in OpenShift, it is time to summon Grafana. Grafana is a visualization powerhouse that allows teams to build custom dashboards, correlate traces with logs and metrics, and gain deep insights into their applications. In this article, we’ll deploy a dedicated Grafana instance for team-a in their namespace, configure a Tempo datasource, and create a dashboard to explore distributed traces.
With this article I would like to summarize and, especially, remember my setup. This is Part 1 of a series of articles that I split up so it is easier to read and understand and not too long. Initially, there will be 6 parts, but I will add more as needed.
After covering the fundamentals and architecture in Part 1, it’s time to get our hands dirty! This article walks through the complete implementation of a distributed tracing infrastructure on OpenShift.
We’ll deploy and configure the Tempo Operator and a multi-tenant TempoStack instance. For S3 storage we will use the integrated OpenShift Data Foundation. However, you can use whatever S3-compatible storage you have available.
With the architecture defined in Part 1 and TempoStack deployed in Part 2, it’s time to tackle the heart of our distributed tracing system: the Central OpenTelemetry Collector. This is the critical component that sits between your application namespaces and TempoStack, orchestrating trace flow, metadata enrichment, and tenant routing.
Discussion
Comments are powered by GitHub Discussions.
To participate, you'll need a GitHub account.
By loading comments, you agree to GitHub's
Privacy Policy.
Your data is processed by GitHub, not by this website.
Discussion
Comments are powered by GitHub Discussions. To participate, you'll need a GitHub account.
By loading comments, you agree to GitHub's Privacy Policy. Your data is processed by GitHub, not by this website.