Created attachment 18853 [details]
pgpdump

Примечание: в процессе написания и допроверки пришёл к выводу,
  что проблема именно в типе ключа по умолчанию, который можно поменять;
  полный ход рассуждений ниже. Желательно, чтобы podsec не давал возможность
  выбрать несовместимый тип ключа в gnupg2, особенно по умолчанию.


Шаги
====

* Достаточно одной серверной машины (ALT Server в минимальном профиле).
* Создать локальный реестр контейнеров и скопировать в него образы, например с registry.k8s.io (по шагам ниже).
* Попробовать инициализировать контейнер kubernetes на данной машине (по https://altlinux.org/Kubernetes).

Указать в шагах ниже переменные:
    * _repo          : Название репозитория (например sisyphus, p11, p10)
    * _registry_repo : Название репозитория в https://registry.altlinux.org - см. https://altlinux.org/Registry_(Новая_структура)
    * _version       : Проверяемую версию kubernetes (например 1.33 (sisyphus), 1.32 (p11), 1.28 (p10))

1. # export _version=1.33 && \
    apt-get install -y podsec podsec-dev fuse-overlayfs trivy trivy-server python3-module-{tomli,requests} kubernetes$_version-kubeadm && \
    podsec-create-policy $(hostname -i) && \
    sed 's|reject|insecureAcceptAnything|g' -i /etc/containers/policy.json && \
    podsec-create-services

2. # podsec-create-imagemakeruser imagemaker
    > ввести пароль (например 1)
    > настройки ключа оставить по умолчанию
    > ввести полное имя imagemaker
    > ввести адрес почты imagemaker@test.ru
    > ввести пароль для gpg ключа (например 1qaz2wsx)
    > остальное по умолчанию

3. # podsec-create-podmanusers poduser
    > ввести пароль (например 1)

4. Скопировать образы в локальный реестр и подписать их:
    # ssh -o "StrictHostKeyChecking no" imagemaker@localhost
        imagemaker$ export _repo=<repo> _registry_repo=<registry_repo> _version=<version> && \
            export _all_images=$(kubeadm config images list --image-repository registry.k8s.io 2>/dev/null) && \
            podman pull --tls-verify $_all_images && \
            podman pull --tls-verify "registry.altlinux.org/$_registry_repo/alt:latest" && \
            podman images | sort && \
            for _image in $_all_images; do
                _local_image=$(echo $_image | sed "s|registry.k8s.io|registry.local/$_repo|g" | sed "s|coredns/coredns|coredns|g") && \
                podman tag "$_image" "$_local_image" && \
                podman push --tls-verify=false --sign-by=imagemaker@test.ru "$_local_image"; \
            done && \
            podman images | sort && \
            exit

5. Настроить HTTPS-доступ к локальному реестру:
    # cd /etc/docker-registry/ && \
        CA_KEY=ca_private_key.pem && \
        CA_CERT=ca_cert.pem && \
        KEY=key.pem && \
        CERT=cert.pem && \
        CSR=cert.csr && \
        SIGNED_CERT=output.pem && \
        CHAIN=combined.pem && \
        SUBJECT=registry.local && \
        CA_NAME="registry.local Test CA" && \
        CERT_NAME="registry.local Test Leaf Certificate" && \
        VALIDITY_DAYS=14 && \
        STRENGTH=4096 && \
            rm -rfv {,**/}*.{pem,csr,crl} && \
            openssl req -x509 -days "$VALIDITY_DAYS" -newkey "rsa:$STRENGTH" -keyout "$CA_KEY" -out "$CA_CERT" -nodes -subj "/C=RU/O=$CA_NAME/" && \
            openssl req -x509 -newkey "rsa:$STRENGTH" -keyout "$KEY" -out "$CERT" -sha256 -days "$VALIDITY_DAYS" -nodes -subj "/C=RU/L=Moscow/O=$CERT_NAME/OU=QA/CN=$SUBJECT" -addext "subjectAltName = DNS:$SUBJECT" && \
            openssl req -new -key "$KEY" -out "$CSR" -subj "/C=RU/L=Moscow/O=$CERT_NAME/OU=QA/CN=$SUBJECT" -addext "subjectAltName = DNS:$SUBJECT" && \
            openssl x509 -req -in "$CSR" -days "$VALIDITY_DAYS" -CA "$CA_CERT" -CAkey "$CA_KEY" -CAcreateserial -out "$SIGNED_CERT" -extfile <(cat /etc/openssl/openssl.cnf <(printf "[my_san_ext]\nsubjectAltName=DNS:$SUBJECT")) -extensions my_san_ext && \
            cat "$SIGNED_CERT" "$CA_CERT" > "$CHAIN" && \
        sed 's/:80/:443/;/\[nosniff\]/a\  tls:\n    certificate: /etc/docker-registry/combined.pem\n    key: /etc/docker-registry/key.pem' -i config.yml && \
        cp ca_cert.pem /etc/pki/ca-trust/source/anchors/ && \
        update-ca-trust && \
        systemctl restart docker-registry && \
        reboot

6. Развернуть kubernetes по https://www.altlinux.org/Kubernetes

Фактический результат
=====================

> I0618 12:41:25.488746    1884 version.go:261] remote version is much newer: v1.33.1; falling back to: stable-1.32
> [init] Using Kubernetes version: v1.32.5
> [preflight] Running pre-flight checks
> [preflight] Pulling images required for setting up a Kubernetes cluster
> [preflight] This might take a minute or two, depending on the speed of your internet connection
> [preflight] You can also perform this action beforehand using 'kubeadm config images pull'
> error execution phase preflight: [preflight] Some fatal errors occurred:
> 	[ERROR ImagePull]: failed to pull image registry.local/p11/kube-apiserver:v1.32.5: failed to pull image registry.local/p11/kube-apiserver:v1.32.5: Source image rejected: openpgp: invalid data: tag byte does not have MSB set
> 	[ERROR ImagePull]: failed to pull image registry.local/p11/kube-controller-manager:v1.32.5: failed to pull image registry.local/p11/kube-controller-manager:v1.32.5: Source image rejected: openpgp: invalid data: tag byte does not have MSB set
> 	[ERROR ImagePull]: failed to pull image registry.local/p11/kube-scheduler:v1.32.5: failed to pull image registry.local/p11/kube-scheduler:v1.32.5: Source image rejected: openpgp: invalid data: tag byte does not have MSB set
> 	[ERROR ImagePull]: failed to pull image registry.local/p11/kube-proxy:v1.32.5: failed to pull image registry.local/p11/kube-proxy:v1.32.5: Source image rejected: openpgp: invalid data: tag byte does not have MSB set
> 	[ERROR ImagePull]: failed to pull image registry.local/p11/coredns:v1.11.3: failed to pull image registry.local/p11/coredns:v1.11.3: Source image rejected: openpgp: invalid data: tag byte does not have MSB set
> 	[ERROR ImagePull]: failed to pull image registry.local/p11/pause:3.10: failed to pull image registry.local/p11/pause:3.10: Source image rejected: openpgp: invalid data: tag byte does not have MSB set
> 	[ERROR ImagePull]: failed to pull image registry.local/p11/etcd:3.5.16-0: failed to pull image registry.local/p11/etcd:3.5.16-0: Source image rejected: openpgp: invalid data: tag byte does not have MSB set
> [preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
> To see the stack trace of this error execute with --v=5 or higher


Ожидаемый результат
===================

Успешная инициализация кластера.


Дополнительно
=============

Проблема, похоже, в версии `gnupg2` и/или отсутствии конкретизации аргументов для него в podsec (может быть podman),
  а именно типа ключа (Ed25519 или RSA; по умолчанию в 2.4 Ed25519). Подробнее:

1. В sisyphus и p11 при установке следующих пакетов по зависимостям устанавливается `gnupg2`, а в p10 - `gnupg2-gostcrypto`:
    > # apt-get install -y podsec podsec-dev fuse-overlayfs trivy trivy-server python3-module-{tomli,requests} kubernetes$_version-kubeadm
    (вдобавок к уже установленному везде `gnupg`)

2. На данный момент в sisyphus и p11 версия `gnupg2` - `2.4`, а в p10 - `2.2`.
    Если установить `gnupg2` в p10 после установки пакетов выше, то инициализация kubernetes тоже успешна.
    Это значит, что дело не в gostcrypto, а в версии `gnupg2`, которая в p11 и sisyphus новее.

3. При этом `gnupg2-gostcrypto` доступен и в p11 (но см. https://bugzilla.altlinux.org/52211).
    Если установить `gnupg2-gostcrypto` в p11 после установки пакетов выше, то инициализация kubernetes становится успешной.
    Это подтверждает, что проблема именно с новой версией `gnupg2`.

    Примечание: для установки gnupg2-gostcrypto может быть необходимо выполнить:

    # apt-repo set p11 && \
      grep 'gostcrypto' /etc/apt/sources.list.d/alt.list || sed -e '/x86_64 /s/$/ gostcrypto/' -i /etc/apt/sources.list.d/alt.list && \
      apt-get update && \
      apt-get install -y gnupg2-gostcrypto

4. Выполнив `# apt-get install -y pgpdump && pgpdump /var/sigstore/keys/imagemaker.pgp`, можно увидеть,
    что ключ для imagemaker генерируется разный на разных системах:
    * Ed25519 в sisyphus, p11 при использовании `gnupg2 (2.4)`
    * RSA 3072bit в p10 при использовании `gnupg2 (2.2)`
    * RSA 2048bit в p10 и p11 при использовании `gnupg2-gostcrypto (2.2)`
    (см. вложение)

    Более того, если выбрать тип ключа RSA при создании imagemaker, то инициализация пройдёт успешно.

5. Это приводит к выводу выше.
    Также см. https://github.com/helm/helm/issues/2843#issuecomment-1462927026

Воспроизводимость
=================

Воспроизводится на виртуальных машинах:

[sisyphus] ALT Server 11.0 x86_64
podsec-1.2.2-alt1.noarch
gnupg-1.4.23-alt5.x86_64
gnupg2-2.4.3-alt1.x86_64

[p11] ALT Server 11.0 x86_64
podsec-1.1.6-alt4.noarch
gnupg-1.4.23-alt4.x86_64
gnupg2-2.4.3-alt1.x86_64


Не воспроизводится на виртуальной машине:

[p10] ALT Server 10.4 x86_64
podsec-1.0.10-alt7.noarch
gnupg-1.4.23-alt4.x86_64
gnupg2-gostcrypto-2.2.19-alt3.x86_64 или gnupg2-2.2.36-alt0.c10.1.x86_64

и в [p11] ALT Server 11.0 x86_64 только с gnupg2-gostcrypto-2.2.19-alt3.x86_64, иначе (с gnupg2-2.4.3-alt1.x86_64) воспроизводится