Configurare le credenziali preparate per i cluster utente

Questo documento mostra come configurare le credenziali preparate per i cluster utente in Google Distributed Cloud.

Con le credenziali preparate, puoi archiviare le credenziali per i cluster utente in Secret nel cluster di amministrazione. In questo modo viene fornito un elemento di sicurezza, perché non devi conservare le password e le chiavi delaccount di serviziot sulla workstation amministrativa durante la creazione dei cluster di utenti.

Tieni presente la seguente limitazione relativa ai cluster avanzati:

• Versione 1.31: le credenziali preparate non sono supportate nei cluster avanzati.
• Versione 1.32 e successive: le credenziali preparate sono supportate nei cluster avanzati.

Prepara i secret nel cluster di amministrazione in anticipo. Poi, quando crei i cluster utente, puoi specificare che determinate credenziali devono essere prese dai secret preparati nel cluster di amministrazione. Puoi anche utilizzare i secret preparati quando esegui la rotazione delle credenziali in un cluster utente.

Prima di iniziare

Crea un cluster di amministrazione se non ne hai già uno.

Panoramica della procedura

1. Compila un file di configurazione dei secret.

2. Nel cluster di amministrazione, crea gruppi di secret. Ogni gruppo di secret si trova nel proprio spazio dei nomi Kubernetes.

3. Crea un cluster utente. Nel file di configurazione del cluster utente, indica che vuoi che le credenziali vengano prese dai secret in uno spazio dei nomi specifico nel cluster di amministrazione.

4. Crea altri gruppi di secret e altre versioni dei tuoi secret in base alle tue esigenze.

5. Aggiorna le credenziali per un cluster utente esistente in base alle necessità.

6. Crea altri cluster utente come preferisci. In ogni file di configurazione del cluster utente, specifica uno spazio dei nomi Secrets. Puoi anche specificare quale versione di un secret vuoi utilizzare per una determinata credenziale.

Compila il file di configurazione dei secret

Genera un modello per un file di configurazione Secrets:

gkectl create-config secrets

Il comando precedente genera un file denominato secrets.yaml. Se vuoi, puoi modificare il nome e la posizione di questo file.

Familiarizza con il file di configurazione leggendo il documento File di configurazione dei secret. Ti consigliamo di tenere aperto questo documento in una scheda o finestra separata.

Nel file di configurazione dei secret, inserisci i valori pertinenti alla tua situazione. Devi inserire un valore per namespace che inizi con gke-onprem-secrets-.

Ecco un esempio di file di configurazione Secrets con un gruppo di secret. Il gruppo ha valori per le credenziali vCenter e quattro chiavi del account di servizio:

apiVersion: v1
kind: ClusterSecrets
secretGroups:
- namespace: "gke-onprem-secrets-user-cluster-1"
  secrets
    vCenter:
      username: "my-vcenter-account"
      password: "U$icUKEW#INE"
    componentAccessServiceAccount:
      serviceAccountKeyPath: "my-key-folder/component-access-key.json"
    registerServiceAccount:
      serviceAccountKeyPath: "my-key-folder/connect-register-key.json"
    stackdriverServiceAccount:
      serviceAccountKeyPath: "my-key-folder/log-mon-key.json"
    cloudAuditLoggingServiceAccount:
      serviceAccountKeyPath: "my-key-folder/audit-log-key.json"

Crea secret preparati

Crea secret preparati nel cluster di amministrazione:

gkectl prepare secrets --kubeconfig ADMIN_CLUSTER_KUBECONFIG --secret-config SECRETS_CONFIG

Sostituisci quanto segue:

• ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione

• SECRETS_CONFIG: il percorso del file di configurazione di Secrets

Visualizzare i secret preparati

Elenca i secret preparati nel cluster di amministrazione:

gkectl list secrets --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Output di esempio:

The following secrets have been found:
- namespace: gke-onprem-secrets-user-cluster-1
  - secrets with name prefix: component-access-sa-creds
    name: component-access-sa-creds.1, version 1, age: 58s
  - secrets with name prefix: cloud-audit-logging-service-account-creds
    name: cloud-audit-logging-service-account-creds.1, version: 1, age: 58s
  - secrets with name prefix: register-service-account-creds
    name: register-service-account-creds.1, version: 1, age: 58s
  - secrets with name prefix: stackdriver-service-account-creds
    name: stackdriver-service-account-creds.1, version: 1, age: 58s
  - secrets with name prefix: vsphere-creds
    name: vsphere-creds.1, version: 1, age: 58s

Puoi anche eseguire kubectl get secrets per elencare i secret in uno spazio dei nomi. Ad esempio:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets --namespace gke-onprem-secrets-user-cluster-1

Output di esempio:

component-access-sa-creds ...
cloud-audit-logging-service-account-creds ...
register-service-account-creds.1 ...
stackdriver-service-account-creds.1 ...
vsphere-creds.1 ...

Nell'output precedente, puoi notare che ogni nome di secret ha un'estensione che indica la versione del secret. In questo esempio, tutti i secret hanno una versione 1.

Creazione di un cluster utente

Segui le istruzioni riportate in Creazione di un cluster utente.

Mentre compili il file di configurazione del cluster utente, inserisci un valore per preparedSecrets.namespace. Questo valore deve corrispondere a uno spazio dei nomi che hai specificato in precedenza in un file di configurazione dei secret.

Esempio:

preparedSecrets:
  namespace: "gke-onprem-secrets-user-cluster-1"

Nel file di configurazione del cluster utente, non specificare valori per i seguenti campi. Questi campi non sono necessari perché Google Distributed Cloud recupera le credenziali e le chiavi dai secret preparati.

• vCenter.credentials.fileRef.path
• componentAccessServiceAccountKeyPath
• loadBalancer.f5BigIP.credentials.fileRef.path
• gkeConnect.registerServiceAccountKeyPath
• stackdriver.serviceAccountKeyPath
• usageMetering.bigQueryServiceAccountKeyPath
• cloudAuditLogging.serviceAccountKeyPath
• privateRegistry.credentials.fileRef.path

Nel file di configurazione del cluster utente, specifica le versioni dei secret preparati che intendi utilizzare. Ecco un esempio che specifica la versione 1 per ognuno dei cinque secret:

vCenter:
  credentials:
    secretRef:
      version "1"
...
componentAccessServiceAccountKey:
  secretRef:
    version: "1"
...
gkeConnect:
  registerServiceAccountKey:
    secretRef:
      version: "1"
...
stackdriver:
  serviceAccountKey:
    secretRef:
      version: "1"
...
cloudAuditLogging:
  serviceAccountKey:
    secretRef:
      version: "1"

Il valore di version deve essere una stringa di numeri interi o la stringa "latest". Se non specifichi un valore per version, viene utilizzata l'ultima versione.

Completa la creazione del cluster utente come descritto in Creazione di un cluster utente.

Creare secret preparati aggiuntivi

Questa sezione mostra come creare la versione 2 di alcuni secret in uno spazio dei nomi esistente.

Crea un nuovo file di configurazione Secrets denominato secrets-2.yaml. Specifica uno spazio dei nomi esistente e fornisci le credenziali per i secret selezionati.

Esempio:

apiVersion: v1
kind: ClusterSecrets
secretGroups:
- namespace: "gke-onprem-secrets-user-cluster-1"
  secrets:
    stackdriverServiceAccount:
      serviceAccountKeyPath: "log-mon-sa-2.json"
    cloudAuditLoggingServiceAccount:
      serviceAccountKeyPath: "audit-log-sa-2.json"

L'esempio precedente fornisce i percorsi delle chiavi per i seguenti secret nello spazio dei nomi gke-onprem-secrets-user-cluster-1.

• Versione 2 del secret stackdriver-service-account-creds
• Versione 2 del secret cloud-audit-logging-service-account-creds

Crea i nuovi secret:

gkectl prepare secrets --kubeconfig ADMIN_CLUSTER_KUBECONFIG --secret-config secrets-2.yaml

Elenca i secret preparati nel cluster di amministrazione:

gkectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG list secrets

Output di esempio:

The following secrets have been found:
- namespace: gke-onprem-secrets-user-cluster-1
  - secrets with name prefix: component-access-sa-creds
    name: component-access-sa-creds.1, version 1, age: 11h
  - secrets with name prefix: cloud-audit-logging-service-account-creds
    name: cloud-audit-logging-service-account-creds.1, version: 1, age: 11h
    name: cloud-audit-logging-service-account-creds.2, version: 2, age: 33m
  - secrets with name prefix: register-service-account-creds
    name: register-service-account-creds.1, version: 1, age: 11h
  - secrets with name prefix: stackdriver-service-account-creds
    name: stackdriver-service-account-creds.1, version: 1, age: 11h
    name: stackdriver-service-account-creds.2, version: 2, age: 33m
  - secrets with name prefix: vsphere-creds
    name: vsphere-creds.1, version: 1, age: 11h

Nell'output precedente, puoi vedere che esistono due versioni del segreto stackdriver-service-account-creds e due versioni del segreto cloud-audit-logging-service-account-creds.

Ruotare le credenziali per un cluster utente

Questa sezione mostra come ruotare le credenziali selezionate per un cluster di utenti esistente.

Prima di ruotare le credenziali, controlla le versioni attuali dei secret utilizzate nel cluster:

gkectl list secrets cluster --cluster-name USER_CLUSTER_NAME  kubeconfig ADMIN_CLUSTER_KUBECONFIG

Output di esempio:

The following prepared secrets have been used for cluster "user-cluster-1":
- namespace: gke-onprem-secrets-user-cluster-1
  secret: vsphere-creds.1, version: 1
  secret: f5-creds.1, version: 1
  secret: component-access-sa-creds.1, version 1
  secret: register-service-account-creds.1, version: 1
  secret: stackdriver-service-account-creds.1, version: 1
  secret: cloud-audit-logging-service-account-creds.1, version: 1

Copia il file di configurazione del cluster utente in un file denominato user-cluster-update.yaml.

In user-cluster-update.yaml, aggiungi le sezioni serviceAccountKey. Ad esempio, il seguente esempio ha serviceAccountKey sezioni in stackdriver e cloudAuditLogging:

stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  serviceAccountKey:
    secretRef:
      version: "2"
cloudAuditLogging:
  projectID: "my-project-123"
  clusterLocation: "us-central-1"
  serviceAccountKey:
    secretRef:
      version: "latest"

L'esempio precedente specifica che quando il cluster utente viene aggiornato, utilizzerà:

• Versione 2 del secret stackdriver-service-account-creds

• L'ultima versione del secret cloud-audit-logging-service-account-creds. In questo esempio, si tratta della versione 2.

Nota: quando aggiorni un secret, il valore che fornisci per secretRef.version deve essere "latest" o una stringa di numeri interi. Non puoi omettere secretRef.version e non puoi impostarlo sulla stringa vuota.

Aggiorna le credenziali del cluster utente:

gkectl update credentials stackdriver --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config user-cluster-2.yaml

gkectl update credentials cloudauditlogging --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config user-cluster-2.yaml

Ora il cluster utente utilizza i seguenti secret preparati:

• Versione 1 di vsphere-creds
• Versione 1 di component-access-sa-creds
• Versione 1 di register-service-account-creds
• Versione 2 di stackdriver-service-account-creds
• Versione 2 di cloud-audit-logging-service-account-creds

Creare secret e cluster utente aggiuntivi

Se prevedi di creare cluster utente aggiuntivi, pensa a come vuoi organizzare i segreti preparati. Ti consigliamo di creare uno spazio dei nomi separato nel cluster di amministrazione per ogni cluster utente. Oppure potresti voler condividere lo stesso spazio dei nomi Secret preparato per diversi o tutti i cluster di utenti.

Ad esempio, supponiamo che Alice, Bob e Carol abbiano ciascuno un cluster utente. Potresti creare tre gruppi di secret come mostrato in questo esempio:

apiVersion: v1
kind: ClusterSecrets
secretGroups:
- namespace: "gke-onprem-secrets-alice"
  secrets:
    vCenter:
      username: "alice"
      password: "zC7r^URDPq2t"
    componentAccessServiceAccount:
      serviceAccountKeyPath: "component-access-sa-a.json"
    registerServiceAccount:
      serviceAccountKeyPath: "register-sa-a.json"
    stackdriverServiceAccount:
      serviceAccountKeyPath: "log-mon-sa-a.json"
    cloudAuditLoggingServiceAccount:
      serviceAccountKeyPath: "audit-log-sa-a.json"
- namespace: "gke-onprem-secrets-bob"
  secrets:
    vCenter:
      username: "bob"
      password: "zC8r^URDPq2t"
    componentAccessServiceAccount:
      serviceAccountKeyPath: "component-access-sa-b.json"
    registerServiceAccount:
      serviceAccountKeyPath: "register-sa-b.json"
    stackdriverServiceAccount:
      serviceAccountKeyPath: "log-mon-sa-b.json"
    cloudAuditLoggingServiceAccount:
      serviceAccountKeyPath: "audit-log-sa-b.json"
- namespace: "gke-onprem-secrets-carol"
  secrets:
    vCenter:
      username: "carol"
      password: "zC9r^URDPq2t"
    componentAccessServiceAccount:
      serviceAccountKeyPath: "component-access-sa-c.json"
    registerServiceAccount:
      serviceAccountKeyPath: "register-sa-c.json"
    stackdriverServiceAccount:
      serviceAccountKeyPath: "log-mon-sa-c.json"
    cloudAuditLoggingServiceAccount:
      serviceAccountKeyPath: "audit-log-sa-c.json"

Nel tempo potresti creare altre versioni dei secret in ogni gruppo di secret.

Nei file di configurazione del cluster utente, fornisci i valori per serviceAccountKey.secretRef.version per specificare le versioni dei tuoi secret che vuoi utilizzare. Puoi impostare il valore su "latest", la stringa vuota o una stringa di numeri interi.

Ad esempio, supponiamo che tutti i tuoi secret abbiano le versioni 1, 2 e 3. Supponiamo che questa sia una parte del file di configurazione del cluster utente per Alice.

apiVersion: v1
kind: UserCluster
name: "user-cluster-alice"
preparedSecrets:
  namespace: "gke-onprem-secrets-alice"
...
vCenter:
  credentials:
gkeConnect:
  projectID: "project-a"
  serviceAccountKey:
    secretRef:
      version: "2"
stackdriver:
  projectID: "project-a"
  clusterLocation: "us-central1"
  serviceAccountKey:
    secretRef:
      version: "latest"
cloudAuditLogging:
  projectID: "project-a"
  clusterLocation: "us-central-1"
  serviceAccountKey:
    secretRef:
      version: ""

Nell'esempio precedente, possiamo vedere:

• Non è stato specificato alcun secretRef per vCenter, quindi il cluster utilizzerà l'ultima versione del secret vsphere-creds nello spazio dei nomi gke-onprem-secrets-alice.

• Il cluster utilizzerà la versione 2 del secret register-service-account-creds nello spazio dei nomi gke-onprem-secrets-alice.

• Il cluster utilizzerà l'ultima versione del secret stackdriver-service-account-creds nello spazio dei nomi gke-onprem-secrets-alice. In questo esempio, si tratta della versione 3.

• La versione di cloudAuditLogging è la stringa vuota, quindi il cluster utilizzerà l'ultima versione del secret cloud-audit-logging-service-account-creds nello spazio dei nomi gke-onprem-secrets-alice. In questo esempio, si tratta della versione 3.

• Non è stato specificato alcun secretRef.version per il account di servizio di accesso ai componenti, quindi il cluster utilizzerà l'ultima versione.

Elimina i secret preparati

Per elencare tutti i secret preparati e i relativi spazi dei nomi:

gkectl list secrets --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Se uno spazio dei nomi secret preparato non viene utilizzato da alcun cluster utente, puoi eliminarlo.

Per eliminare uno spazio dei nomi secret preparato e tutti i secret al suo interno:

gkectl delete secret –namespace PREPARED_SECRET_NAMESPACE \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Se un secret preparato da un singolo utente non viene utilizzato da alcun cluster di utenti, puoi eliminarlo.

Per eliminare un singolo segreto preparato:

gkectl delete secret –namespace PREPARED_SECRET_NAMESPACE \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --secret-name SECRET

Documenti correlati

• File di configurazione dei secret
• File di configurazione del cluster utente
• Creare un cluster utente
• Crea service account