Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Cloud de Confiance di S3NS. Per maggiori dettagli, consulta Differenze rispetto a Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Sincronizza gli artefatti OCI da Artifact Registry

Questa pagina mostra come creare e pubblicare l'immagine in un repository in Artifact Registry con crane e oras.

Puoi configurare Config Sync per la sincronizzazione dalle immagini OCI utilizzando Artifact Registry. Per utilizzare questa funzionalità, devi abilitare le API RootSync e RepoSync.

Informazioni su Artifact Registry

Artifact Registry è un servizio completamente gestito che supporta sia le immagini container sia gli artefatti non container. Ti consigliamo Artifact Registry per l'archiviazione e la gestione delle immagini container su Cloud de Confiance by S3NS. Esistono molti strumenti disponibili per eseguire il push degli artefatti in Artifact Registry. Ad esempio, puoi eseguire il push di un'immagine Docker o utilizzare la libreria go-containerregistry per lavorare con i container registry. Scegli lo strumento più adatto alle tue esigenze.

Prima di iniziare

Installa Google Cloud CLI.

Nota: se hai già installato gcloud CLI, assicurati di avere l'ultima versione eseguendo gcloud components update.
Configura gcloud CLI per utilizzare la tua identità federata.

Per ulteriori informazioni, vedi Accedi a gcloud CLI con la tua identità federata.
Per inizializzare gcloud CLI, esegui questo comando:
```
gcloud init
```
Crea o seleziona un Cloud de Confiance progetto.
Ruoli richiesti per selezionare o creare un progetto
- Seleziona un progetto: la selezione di un progetto non richiede un ruolo IAM specifico. Puoi selezionare qualsiasi progetto per il quale ti è stato concesso un ruolo.
- Crea un progetto: per creare un progetto, devi disporre del ruolo Autore progetto (roles/resourcemanager.projectCreator), che contiene l'autorizzazione resourcemanager.projects.create. Scopri come concedere i ruoli.
Nota: se non prevedi di conservare le risorse che crei in questa procedura, crea un progetto invece di selezionarne uno già esistente. Una volta completata questa procedura, puoi eliminare il progetto e tutte le relative risorse.
- Creare un progetto Cloud de Confiance :
```
gcloud projects create PROJECT_ID
```
  Sostituisci PROJECT_ID con un nome per il progetto Cloud de Confiance che stai creando.
- Seleziona il progetto Cloud de Confiance che hai creato:
```
gcloud config set project PROJECT_ID
```
  Sostituisci PROJECT_ID con il nome del progetto Cloud de Confiance .
Verifica che la fatturazione sia attivata per il tuo progetto Cloud de Confiance .
Abilita le API GKE, Config Sync e Artifact Registry:
Ruoli richiesti per abilitare le API
Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo dei servizi (roles/serviceusage.serviceUsageAdmin), che include l'autorizzazione serviceusage.services.enable. Scopri come concedere i ruoli.
```
gcloud services enable container.googleapis.com  anthosconfigmanagement.googleapis.com  artifactregistry.googleapis.com
```

Crea o accedi a un cluster che soddisfi i requisiti per Config Sync e che utilizzi l'ultima versione di Config Sync.
Installa la CLI nomos o esegui l'upgrade all'ultima versione.
(Facoltativo) Se vuoi utilizzare Cosign per verificare le firme delle immagini OCI, installa quanto segue:

Cosign per firmare le immagini OCI.
OpenSSL per generare le credenziali per il server webhook.
Docker per creare ed eseguire il push dell'immagine del server webhook di ammissione.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Cloud de Confiance by S3NS:

Crea un repository Artifact Registry

In questa sezione, crei un repository Artifact Registry. Per scoprire di più sulla creazione di repository Artifact Registry, consulta Crea repository.

Crea un repository Artifact Registry:

gcloud artifacts repositories create AR_REPO_NAME \
   --repository-format=docker \
   --location=AR_REGION \
   --description="Config Sync repo" \
   --project=PROJECT_ID

Sostituisci quanto segue:

PROJECT_ID: l'ID progetto dell'organizzazione.
AR_REPO_NAME: l'ID del repository.
AR_REGION: la posizione regionale o multiregionale del repository.

Variabili utilizzate nelle seguenti sezioni:

FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity Federation for GKE, questo valore è uguale a PROJECT_ID. Se utilizzi Workload Identity Federation for GKE del parco risorse, questo è l'ID progetto del parco risorse a cui è registrato il tuo cluster.
GSA_NAME: il nome del account di servizio Google personalizzato che vuoi utilizzare per connetterti ad Artifact Registry.
KSA_NAME: il account di servizio Kubernetes per il reconciler.
- Per i repository radice, se il nome RootSync è root-sync, aggiungi root-reconciler. In caso contrario, aggiungi root-reconciler-ROOT_SYNC_NAME.
- Per i repository dello spazio dei nomi, se il nome RepoSync è repo-sync, aggiungi ns-reconciler-NAMESPACE. In caso contrario, aggiungi ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH dove REPO_SYNC_NAME_LENGTH è il numero di caratteri in REPO_SYNC_NAME.

Concedere l'autorizzazione di lettura

Utilizza un account di servizio Kubernetes per l'autenticazione in Artifact Registry completando i seguenti passaggi:

Concedi il ruolo IAM Lettore Artifact Registry (roles/artifactregistry.reader) al account di servizio Kubernetes che ha il pool Workload Identity Federation per GKE:

gcloud artifacts repositories add-iam-policy-binding AR_REPO_NAME \
   --location=AR_REGION \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.s3ns.svc.id.goog[config-management-system/KSA_NAME]" \
   --role=roles/artifactregistry.reader \
   --project=PROJECT_ID

Esegui il push di un'immagine nel repository Artifact Registry

In questa sezione, crei un'immagine OCI ed esegui il push in Artifact Registry.

Crea un file manifest Namespace:

cat <<EOF> test-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: test
EOF

Accedi ad Artifact Registry:

gcloud auth configure-docker AR_REGION-docker.pkg.dev

Crea un pacchetto dell'immagine ed eseguine il push in Artifact Registry:
crane
I comandi in questa sezione utilizzano crane per interagire con immagini e registri remoti.
1. Comprimi il file:
  
  tar -cf test-namespace.tar test-namespace.yaml
2. Installa lo strumento crane.
3. Esegui il push dell'immagine in Artifact Registry:
  
  crane append -f test-namespace.tar -t AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME/test-namespace:v1
oras
I comandi in questa sezione utilizzano oras per interagire con immagini e registri remoti.
1. Comprimi il file:
  
  tar -czf test-namespace.tar.gz test-namespace.yaml
2. Installa lo strumento oras.
3. Esegui il push dell'immagine in Artifact Registry:
  
  oras push AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME/test-namespace:v1 test-namespace.tar.gz
Attenzione :Config Sync richiede che il livello OCI sia compresso nel formato tar o tar+gzip. Altri formati (ad esempio tar+bz2) non sono riconosciuti da Config Sync. Il passaggio da un REPO valido a un'immagine OCI con un formato non supportato comporterà l'eliminazione delle risorse gestite senza errori.

Configura Config Sync per la sincronizzazione dall'immagine

In questa sezione creerai un oggetto RootSync e configurerai Config Sync per la sincronizzazione dall'immagine OCI.

Crea un oggetto RootSync con un nome univoco:

cat <<EOF>> ROOT_SYNC_NAME.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceFormat: unstructured
  sourceType: oci
  oci:
    image: AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME/test-namespace:v1
    dir: .
    auth: k8sserviceaccount
EOF

Sostituisci ROOT_SYNC_NAME con il nome dell'oggetto RootSync. Il nome deve essere univoco nel cluster e non deve contenere più di 26 caratteri. Per l'elenco completo delle opzioni durante la configurazione degli oggetti RootSync, vedi Campi RootSync e RepoSync.

Applica l'oggetto RootSync:
```
kubectl apply -f ROOT_SYNC_NAME.yaml
```

Verifica che Config Sync stia sincronizzando dall'immagine:

nomos status --contexts=$(kubectl config current-context)

Dovresti vedere un output simile al seguente esempio:

Connecting to clusters...

*publish-config-registry
   --------------------
   <root>:root-sync-test   AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME/test-namespace:v1   
   SYNCED                  05e6a6b77de7a62286387cfea833d45290105fe84383224938d7b3ab151a55a1
   Managed resources:
      NAMESPACE   NAME             STATUS    SOURCEHASH
                  namespace/test   Current   05e6a6b

Ora hai sincronizzato correttamente un'immagine con il tuo cluster.

(Facoltativo) Verifica le firme dell'origine OCI

Puoi verificare l'autenticità delle immagini di origine OCI prima che le configurazioni vengano applicate ai tuoi cluster. Questo metodo utilizza un oggetto ValidatingWebhookConfiguration e un server webhook di convalida per intercettare le richieste di aggiornamento per gli oggetti RootSync e RepoSync. Config Sync aggiorna l'annotazione configsync.gke.io/image-to-sync degli oggetti RootSync e RepoSync dopo aver recuperato correttamente un nuovo digest dell'immagine. Il server webhook di convalida confronta i valori tra la vecchia annotazione e la nuova ed esegue la convalida con uno strumento di convalida come Cosign quando viene rilevata una modifica.

Configurare un server di verifica della firma

Per garantire l'autenticità delle origini OCI, è necessario un server HTTP per verificare le firme. Puoi utilizzare gli esempi nel repository di esempi di Config Sync o utilizzare la tua immagine Docker.

Se vuoi utilizzare il campione fornito, completa i seguenti passaggi:
1. Clona il repository di esempio:
```
git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples/
```
2. Passa alla directory che contiene gli esempi del server di verifica della firma:
```
cd anthos-config-management-samples/tree/main/pre-sync/oci-image-verification
```
Per creare un'immagine Docker per il server di verifica della firma ed eseguirne il push in un registro delle immagini, esegui questo comando:
```
docker build -t SIGNATURE_VERIFICATION_SERVER_IMAGE_URL:latest . && docker push SIGNATURE_VERIFICATION_SERVER_IMAGE_URL:latest
```
Sostituisci SIGNATURE_VERIFICATION_SERVER_IMAGE_URL con l'URL dell'immagine del server di verifica della firma.

Autenticarsi ai servizi

Per configurare il server di verifica della firma, devi autenticarti in Artifact Registry, nel client Cosign e nel server webhook.

Crea uno spazio dei nomi:

kubectl create ns signature-verification

Per eseguire l'autenticazione ad Artifact Registry con un ServiceAccount Kubernetes, completa i seguenti passaggi:
1. Crea un ServiceAccount Kubernetes nello spazio dei nomi che hai creato:
```
kubectl create sa signature-verification-sa -n signature-verification
```
2. Aggiungi l'associazione di policy IAM per il ruolo Artifact Registry Reader (roles/artifactregistry.reader):
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
   --location=REPOSITORY_LOCATION \
   --member="serviceAccount:PROJECT_ID.s3ns.svc.id.goog[signature-verification/signature-verification-sa]" \
   --role=roles/artifactregistry.reader \
   --project=PROJECT_ID
```
  Sostituisci quanto segue:
  - REPOSITORY_NAME: il nome del repository Artifact Registry in cui memorizzi le immagini OCI.
  - REPOSITORY_LOCATION: la posizione del repository Artifact Registry.
Per eseguire l'autenticazione al client Cosign, completa i seguenti passaggi:
1. Genera una coppia di chiavi Cosign. Questo comando genera una chiave pubblica e una chiave privata:
```
cosign generate-key-pair
```
2. Archivia la chiave pubblica in un secret Kubernetes nello spazio dei nomi che hai creato:
```
kubectl create secret generic cosign-key --from-file=cosign.pub -n signature-verification
```

Per autenticare il server di verifica della firma, completa i seguenti passaggi:

Per criptare la comunicazione all'interno del server di verifica della firma, genera un certificato TLS e una chiave privata con OpenSSL:

openssl req -nodes -x509 -sha256 -newkey rsa:4096 \
-keyout tls.key \
-out tls.crt \
-days 356 \
-subj "/CN=signature-verification-service.signature-verification.svc"  \
-addext "subjectAltName = DNS:signature-verification-service,DNS:signature-verification-service.signature-verification.svc,DNS:signature-verification-service.signature-verification"

Archivia le credenziali che hai generato in un secret Kubernetes:

kubectl create secret tls webhook-tls --cert=tls.crt --key=tls.key -n signature-verification

Recupera i contenuti codificati in base64 di tls.cert. Questo è necessario per la configurazione del webhook di convalida che crei nella sezione successiva:
```
cat tls.crt | base64 -w 0.
```

Esegui il deployment del webhook di ammissione

Puoi utilizzare i seguenti esempi per creare un deployment per il server di verifica della firma e una configurazione webhook di convalida.

Crea un deployment per il server di verifica della firma salvando il seguente file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: signature-verification-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: signature-verification-server
  template:
    metadata:
      labels:
        app: signature-verification-server
    spec:
      serviceAccountName: signature-verification-sa
      containers:
      - name: signature-verification-server
        command:
        - /signature-verification-server
        image: SIGNATURE_VERIFICATION_SERVER_IMAGE_URL
        imagePullPolicy: Always
        ports:
        - containerPort: 10250
        volumeMounts:
        - name: tls-certs
          mountPath: "/tls"
        - name: cosign-key
          mountPath: "/cosign-key"
      volumes:
      - name: cosign-key
        secret:
          secretName: cosign-key
      - name: tls-certs
        secret:
          secretName: webhook-tls
---
apiVersion: v1
kind: Service
metadata:
  name: signature-verification-service
spec:
  ports:
  - port: 10250
    targetPort: 10250
  selector:
    app: signature-verification-server

Sostituisci SIGNATURE_VERIFICATION_SERVER_IMAGE_URL con l'URL completo dell'immagine del server di verifica della firma.

Applica il deployment al cluster:

kubectl apply -f signature-verification-deployment.yaml -n signature-verification

Crea una configurazione webhook di convalida salvando il seguente file:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: image-verification-webhook
webhooks:
- name: imageverification.webhook.com
  clientConfig:
    service:
      name: signature-verification-service
      namespace: signature-verification
      path: "/validate"
      port: 10250
    caBundle: CA_BUNDLE
  rules:
  - apiGroups:
    - configsync.gke.io
    apiVersions:
    - v1beta1
    - v1alpha1
    operations:
    - UPDATE
    resources:
    - 'rootsyncs'
    - 'reposyncs'
    scope: '*'
  admissionReviewVersions: ["v1", "v1beta1"]
  sideEffects: None

Sostituisci CA_BUNDLE con i contenuti codificati in base64 di tls.cert.

Applica la configurazione del webhook di convalida al cluster:

kubectl apply -f signature-verification-validatingwebhookconfiguration.yaml

Controllare i log per individuare errori di verifica delle immagini

Una volta configurato il server di verifica delle immagini, tutti i tentativi di sincronizzazione da immagini OCI non firmate non dovrebbero andare a buon fine.

Per verificare la presenza di errori di verifica della firma, visualizza i log del server di verifica della firma eseguendo i seguenti comandi:

Controlla i log di kubectl:

kubectl logs deployment  signature-verification-server -n  signature-verification

Gli errori di kubectl relativi alla verifica della firma sono simili ai seguenti:

main.go:69: error during command execution: no signatures found

Controlla i log di Config Sync:

nomos status

Gli errori di Config Sync relativi alla verifica della firma sono simili ai seguenti:

Error:   KNV2002: admission webhook "imageverification.webhook.com" denied the request: Image validation failed: cosign verification failed: exit status 10, output: Error: no signatures found

Se non ricevi errori, puoi verificare che l'immagine firmata sia l'oggetto sincronizzato esaminando la configurazione di RootSync o RepoSync:

`RootSync`

 kubectl get rootsync ROOTSYNC_NAME -n config-management-system -oyaml

Sostituisci ROOTSYNC_NAME con il nome del tuo RootSync.

`RepoSync`

 kubectl get reposync REPOSYNC_NAME -n REPOSYNC_NAMESPACE -oyaml