Skip to content

Optimization of journalctl usage in CIS hardening guides #573

Description

@brinker-tbaker

on bare-metal systems where a node is not re-provisioned between upgrades and a long journal exists, the journalctl command used for CIS scanning can take an extremely long time (hours or more).

Instead of scanning the entire journal with journalctl -m -u k3s would it make more sense to scan the journal since the last time k3s was started by using the _SYSTEMD_INVOCATION_ID field as a filter?

This command shows all k3s logs since the last time it started
journalctl -m -u k3s _SYSTEMD_INVOCATION_ID=$(systemctl show -p InvocationID --value k3s.service)

for example for check 4.2.1 (Ensure that the --anonymous-auth argument is set to false)
/bin/sh -c 'if test $(journalctl -m -u k3s | grep "Running kube-apiserver" | wc -l) -gt 0; then journalctl -m -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "anonymous-auth" | grep -v grep; else echo "--anonymous-auth=false"; fi'

would change to
/bin/sh -c 'if test $(journalctl -m -u k3s _SYSTEMD_INVOCATION_ID=$(systemctl show -p InvocationID --value k3s.service) | grep "Running kube-apiserver" | wc -l) -gt 0; then journalctl -m -u k3s _SYSTEMD_INVOCATION_ID=$(systemctl show -p InvocationID --value k3s.service) | grep "Running kube-apiserver" | tail -n1 | grep "anonymous-auth" | grep -v grep; else echo "--anonymous-auth=false"; fi'

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions