Obiettivi

• Comprendere i benefici della condivisione delle risorse tra gli account
• Scopri le diverse tecniche per condividere le risorse tra gli account

Panoramica sulla condivisione delle risorse

Non è raro trovare l'accesso a più applicazioni e utilizzare la stessa risorsa o parti di essa. Un esempio è quando le applicazioni e gli ambienti di calcolo devono vivere sulla stessa rete aziendale. Un altro scenario è che i log di sicurezza vengono raccolti nella memoria centrale. In un'architettura di microservizio, ci richiede di configurare i servizi per accedere e utilizzare risorse esterne. A loro volta, le risorse condivise devono autorizzare l'accesso e la rete tra loro è configurata per supportare tale collaborazione, ma non di più.

Alcuni casi di utilizzo tipici di condivisione delle risorse sono:

• Gestione centrale dell'infrastruttura di sicurezza. Monitora la sicurezza da un account dedicato e aggrega i log di protezione in un singolo luogo. Gestire tutte le chiavi di crittografia in KMS (central key management systems).
• Coordinamento di indirizzi di rete e sottoreti. Le applicazioni e gli ambienti di elaborazione devono adattarsi alla stessa rete e richiedere la condivisione di intervalli di indirizzi e nomi di dominio.
• Gestione centrale delle risorse per il ripristino di emergenza, inclusi i servizi di backup come IBM Cloud Backup for Classic. Le applicazioni e i relativi servizi possono essere progettati per l'alta disponibilità, ma nel peggiore dei casi potrebbero essere disponibili ulteriori risorse organizzate a livello centrale. Ciò include la conservazione di più copie di risorse disponibili in tutto il mondo, ad esempio, memorizzate in replicati Object Storage bucket.
• Controlla i costi condividendo servizi più costosi dove possibile. Non tutti i progetti di sviluppo devono avere tutti i servizi distribuiti come istanze dedicate. Spesso, è sufficiente condividere le istanze del servizio - all'interno degli account o tra di essi. Anche per gli ambienti di produzione, le istanze del servizio potrebbero essere condivise in base al fattore costo / valore e alla fattibilità tecnica. Questo può essere organizzato limitando i servizi disponibili in un account utilizzando cataloghi privati e limitando il catalogo pubblico, quindi fornendo centralmente istanze di servizi limitati.
• Gestione centrale delle risorse a livello aziendale o per un'unità aziendale. Questo potrebbe essere un asset necessario per il branding o i modelli gestiti centralmente, le immagini di base (macchine virtuali, contenitori) e altro ancora. Di nuovo, i cataloghi privati e Container Registry sono servizi tipici.
• Rendere disponibili risorse scarse a più utenti. A volte, un tipo di risorsa è disponibile solo in quantità limitata. Condividendo, più applicazioni possono trarne vantaggio. Ciò può richiedere una limitazione della frequenza.

Condivisione delle risorse di sicurezza

Spesso, la sicurezza viene gestita a livello aziendale con regole a livello aziendale. Pertanto, l'applicazione è gestita anche a livello centrale. Questo è ancora vero con i workload che si spostano in ambienti cloud. La condivisione delle risorse è alla base della gestione centralizzata della sicurezza e della valutazione e dell'applicazione della conformità.

Il diagramma precedente mostra i seguenti scenari:

1. Le istanze di Object Storage e Databases for MongoDB in Account A e Account B utilizzano le chiavi di crittografia gestite nell'account principale in Key Protect.
2. Security and Compliance Center in Account principale gestisce le risorse in tutti i tre account (vedi le righe nere sopra).
3. Le istanze di IBM Cloud Activity Tracker Event Routing nell'account A e nell'account B indirizzano i registri di audit a IBM Cloud Logs nell'account principale (vedere le linee blu sopra). Il IBM Cloud Logs è configurato per persistere i log di audit per soddisfare i requisiti di analisi e aziendali.

La condivisione può essere tra account in un IBM Cloud Enterprise o senza un'organizzazione aziendale formale.

Condivisione delle risorse di rete

La progettazione e lo sviluppo di app native cloud in un contesto aziendale spesso implica il coordinamento delle risorse di rete come intervalli di indirizzi e sottoreti, nomi di dominio e instradamento del traffico. I diversi account, le applicazioni e gli ambienti di elaborazione devono adattarsi alla rete e alla sua struttura. Ciò richiede la condivisione delle risorse di rete.

1. Il servizio Transit Gateway è utilizzato per interconnettere gli ambienti VPC e l'infrastruttura classica tra i tre account.
2. Ogni account ha una istanza DNS Services per gestire i nomi di dominio privati. Le istanze sono connesse per condividere le zone DNS.

Implementazione della condivisione delle risorse

Come indicato nell'introduzione, è prassi comune accedere ai servizi al di fuori di un account (cloud). A seconda del livello di integrazione, esistono diversi modi per autorizzare l'accesso al servizio e implementare l'autenticazione. Le opzioni disponibili sono illustrate di seguito.

Autorizzazione service - to - service

Un approccio integrato più stretto per un servizio che accede ad un altro è quello di stabilire le autorizzazioni service - to - service(autorizzaziones2s). Crei una politica IAM (Identity and Access Management) IBM Cloud che autorizza un servizio di origine ad accedere a un servizio di destinazione. Poiché l'autenticazione viene eseguita identificando il servizio di origine che richiede l'accesso, non sono necessarie credenziali sotto forma di parole d'ordine o chiavi API. L'autenticazione e l'autorizzazione vengono gestite automaticamente a causa della politica IAM creata.

Autorizzazioni tra conti

IAM supporta la creazione di autorizzazioni service - to - Service tra un servizio di origine in un altro conto IBM Cloud e una destinazione in quello corrente. Pertanto, consente la condivisione di risorse tra account creando una politica di autorizzazione IAM. Tali politiche possono essere create in molti modi, incluso nella console del browser, come mostrato di seguito, utilizzando la CLI o eseguendo il codice Terraform.

Nei seguenti esempi, a una specifica istanza Object Storage nell'account origine viene concesso il ruolo Reader per tale istanza Key Protect identificata nell'account corrente.

Quanto segue mostra il codice Terraform per la creazione di una risorsa con la stessa politica di autorizzazione IAM:

resource "ibm_iam_authorization_policy" "cross_account_policy" {
  source_service_account      = data.ibm_iam_account_settings.account_a_settings.account_id
  source_service_name         = "cloud-object-storage"
  source_resource_instance_id = data.ibm_resource_instance.cos_resource_instance.guid

  target_service_name         = "kms"
  target_resource_instance_id = data.ibm_resource_instance.kms_resource_instance.guid

  roles                       = ["Reader"]
  description                 = "read access on Key Protect in Main Account for Account A"
}

La stessa politica di autorizzazione può essere creata utilizzando la CLI IBM Cloud con il comando iam service - policy - create:

ibmcloud iam authorization-policy-create cloud-object-storage kms Reader --source-service-account source_account_id --source-service-instance-id cos_instance_id --target-service-instance-id kms_instance_id

La console, il fornitore Terraform e la CLI utilizzano tutti l'API di gestione della politica IAM per creare la politica.

Come passo successivo, con la politica di autorizzazione in atto, potrebbe essere creato un bucket di archiviazione codificato utilizzando una chiave root Key Protect. Quanto segue mostra il codice Terraform che utilizza la risorsa ibm_cos_bucket. L'attributo key_protect contiene il CRN della chiave root.

resource "ibm_cos_bucket" "cos_bucket" {
  bucket_name          = "cos-bucket"
  resource_instance_id = data.ibm_resource_instance.cos_resource_instance.id
  region_location      = var.region
  key_protect          = data.ibm_kms_key.central_kms_root_key.id
  storage_class        = "smart"
}

Puoi trovare ulteriori esempi nel repository GitHub cross - account - resource - sharing.

Autorizzazioni tipiche da servizio a servizio

Una dipendenza da un KMS (key management service) come Key Protect e Hyper Protect Crypto Services è tipica per soluzioni basate sul cloud. Un'istanza KMS contiene chiavi root per la crittografia gestita dal cliente. La maggior parte dei servizi supporta chiavi di crittografia controllate dal cliente. Invece di cloud - object - storage (Object Storage) nell'esempio precedente, molti altri servizi possono utilizzare un'istanza KMS condivisa tra gli account.

Altri servizi tipici (di destinazione) per l'autorizzazione service - to - service e candidati per la condivisione delle risorse includono:

• Object Storage: diversi servizi richiedono o sono in grado di archiviare dati e file di log in un bucket di archiviazione. Ciò include l'archiviazione dei log di accesso e dei dati di monitoraggio. Altri servizi devono accedere ai bucket per eseguire l'analisi dei dati. E ancora un'altra categoria di servizi ha bisogno di accesso per sottoscrivere notifiche di modifica per attivare l'esecuzione delle azioni.
• Event Notifications: per inviare informazioni sugli eventi ai sottoscrittori, le istanze del servizio devono accedere a un'istanza Event Notifications.
• Secrets Manager: questo servizio archivia e fornisce ad altri servizi chiavi API IAM, certificati SSL/TLS e altri segreti. Pertanto, i servizi dipendenti (origine) devono accedere a Secrets Manager.
• Cloud Internet Services (CIS): gestisce i nomi dominio e altri dati di rete e, quindi, può essere utilizzato per, ad esempio, la convalida del certificato.
• IBM Cloud Logs Routing e IBM Cloud Activity Tracker Event Routing: necessita dell'accesso del servizio a obiettivi come IBM Cloud Logs.

Notare che l'elenco precedente non è completo.

Riepilogo

Accedere alle risorse in account diversi, anche condividere le risorse è una pratica comune. Esistono diversi casi di utilizzo in cui gli utenti traggono vantaggio dalla condivisione delle risorse. Sono stati discussi nella panoramica. Una combinazione di identità utente e password o una chiave API per accedere a una risorsa spesso serve come autenticazione. L'accesso può essere limitato ad una serie di privilegi, ad esempio, consentendo solo l'accesso in lettura o altre azioni limitate. A volte, questo tipo di credenziali può essere creato e gestito dalla risorsa di accesso come un'applicazione o un ambiente di calcolo ("bind del servizio"). Un'integrazione ancora più stretta che non richiede credenziali è il concetto di autorizzazione service - to - service IBM Cloud. La risorsa di accesso (origine) e la risorsa a cui si accede (destinazione) sono identificate dalle relative proprietà (autenticazione) e viene assegnato un ruolo di accesso (autorizzazione). Tale relazione può essere stabilita anche oltre i confini del conto. Ciò consente una condivisione delle risorse tra account semplice da configurare, ma allo stesso tempo sicura.

Puoi trovare esempi di codice su come configurare la condivisione delle risorse per parte di questo servizio nel repository GitHub cross - account - resource - sharing.

Risorse correlate

Il seguente documento fornisce i dettagli su alcuni scenari cross - account:

• IBM Cloud Le chiavi API per un utente possono avere un ambito tra più account

Post del blog correlati alla condivisione di risorse tra più account:

• Configurazione multi - account Terraform per IBM Cloud
• Suggerimenti e suggerimenti per l'utilizzo della CLI IBM Cloud discute IBMCLOUD_HOME che può essere utilizzato per gestire più account dalla CLI.