KubeOpsDoku – security

Kubeopsctl: How to set up SSH keys

Mon, 01 Jan 0001 00:00:00 +0000

To securely access the kubeops master and worker machines, you need to create a ssh-key-pair (private and public key) on the admin machine. Afterwards copy the public key onto each machine.

Install SSH Client

Most Linux distributions come with an SSH client pre-installed. If its not installed, you can install it using your distributions package manager.

Important For installing new additional software you may need permissions (e.g. root or sudo).

For RHEL8 OS use following command.

sudo dnf install -y openssh-client

Generate SSH Keys

If you do not already have an SSH key or if you want to generate a new key pair specifically for this connection, follow these steps.

Run the command

ssh-keygen

Follow the prompts to choose a file location and passphrase (optional but recommended for added security).

Copy the Public Key to the Remote Machine

To avoid password prompts every time you connect, you can authorize your public key on the remote machine.

You can manually copy the public key to the servers authorized keys using the command ssh-copy-id.

ssh-copy-id <username>@<remote_host>

Replace <username>@<remote_host> with your actual username and the remote machine‘s IP address or hostname.

If ssh-copy-id is not available, you can use the following command:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Additional Information

For more information about commands see the documentation of your respective operating system.

For ssh or ssh-keygen you can use the manual pages:

man ssh

man ssh-keygen

Kosi: Software Bill of Materials (SBOM)

Mon, 01 Jan 0001 00:00:00 +0000

KubeOps publishes a Software Software Bill of Materials (SBOM) for the kosi command-line tooling that ships in the package repositories. It lists every bundled component with its exact version and license, in CycloneDX format. The published document is the authoritative source — link to it rather than copying its contents, so the list never drifts out of date.

Download

The SBOM is served at a fixed path in each package repository. Both repositories ship the same SBOM document, so the only difference is the retrieval URL for your platform.

curl -fsSLO https://packagerepo.kubeops.net/rpm/sbom/kosi-2.15.0.5_Beta1-0.x86_64.xml

You can checkout all SBOMs here sbom

curl -fsSLO https://packagerepo.kubeops.net/deb/pool/main/sbom/kosi-2.15.0.5_Beta1-0.x86_64.xml

You can checkout all SBOMs here sbom

Using the SBOM

The CycloneDX document can be fed directly into SBOM-aware vulnerability scanners and license-compliance tooling without re-resolving dependencies, for example:

grype sbom:./kosi-bom.xml   # vulnerability scan
trivy sbom ./kosi-bom.xml   # vulnerability scan

Scanner output reflects advisories at the time you run the scan, not at the time the SBOM was generated. Re-run scans regularly rather than relying on a single point-in-time result.

Kubeopsctl-2.0: Software Bill of Materials (SBOM)

Mon, 01 Jan 0001 00:00:00 +0000

KubeOps publishes a Software Software Bill of Materials (SBOM) for the kubeopsctl command-line tooling that ships in the package repositories. It lists every bundled component with its exact version and license, in CycloneDX format. The published document is the authoritative source — link to it rather than copying its contents, so the list never drifts out of date.

Download

The SBOM is served at a fixed path in each package repository. Both repositories ship the same SBOM document, so the only difference is the retrieval URL for your platform.

curl -fsSLO https://packagerepo.kubeops.net/rpm/sbom/kubeopsctl-2.2.0.0_Beta1-0.x86_64.xml

You can checkout all SBOMs here sbom

curl -fsSLO https://packagerepo.kubeops.net/deb/pool/main/sbom/kubeopsctl-2.2.0.0_Beta1-0.x86_64.xml

You can checkout all SBOMs here sbom

Using the SBOM

The CycloneDX document can be fed directly into SBOM-aware vulnerability scanners and license-compliance tooling without re-resolving dependencies, for example:

grype sbom:./kubeopsctl-bom.xml   # vulnerability scan
trivy sbom ./kubeopsctl-bom.xml   # vulnerability scan

Scanner output reflects advisories at the time you run the scan, not at the time the SBOM was generated. Re-run scans regularly rather than relying on a single point-in-time result.