Objetivos

• Entenda os benefícios do compartilhamento de recursos através de contas
• Conheça diferentes técnicas para compartilhar recursos através de contas

Visão geral do compartilhamento de

Não é incomum encontrar vários aplicativos de acesso e usar o mesmo recurso ou partes dele. Um exemplo é quando os aplicativos e ambientes de computação têm que viver na mesma rede corporativa. Outro cenário é que os logs de segurança são coletados no armazenamento central. Em uma arquitetura de microsserviços, ela requer que a gente configure os serviços para acessar e utilizar recursos externos. Por sua vez, os recursos compartilhados devem autorizar o acesso, e a rede entre eles está configurada para suportar tal colaboração, mas não mais.

Alguns casos de uso típico de compartilhamento de recursos são:

• Gestão central da infraestrutura relacionada à segurança. Monitore a segurança a partir de uma conta dedicada, e agrega logs de segurança em um único lugar. Gerenciar todas as chaves de criptografia em sistemas de gerenciamento de chaves centrais (KMS).
• Coordenação de endereços de rede e sub-redes. Aplicativos e ambientes de cálculo precisam se encaixar na mesma rede e requerer o compartilhamento de intervalos de endereços e nomes de domínio.
• Gerenciamento central de recursos para recuperação de desastres, incluindo serviços de backup como IBM Cloud Backup for Classic. Os aplicativos e seus serviços podem ser projetados para alta disponibilidade, mas recursos adicionais organizados centralmente podem estar disponíveis para recuar para no pior dos casos. Isso inclui a realização de múltiplas cópias de recursos disponíveis no mundo todo, por ex., armazenados em replicados Object Storage buckets.
• Controle custos com o compartilhamento de serviços mais caros sempre que possível. Nem todo projeto de desenvolvimento precisa ter todos os serviços implementados como instâncias dedicadas. Muitas vezes, é suficiente para compartilhar instâncias de serviço-dentro de contas ou em frente. Mesmo para ambientes de produção, as instâncias de serviço podem ser compartilhadas dependendo de seu fator de custo / valor e viabilidade técnica. Isso pode ser organizado restringindo os serviços disponíveis em uma conta utilizando-se catálogos particulares e restringindo o catálogo público, então fornecendo centralmente instâncias de serviços restritos.
• Gerenciamento central de recursos em um nível corporativo ou para uma unidade de negócios. Isso pode ser ativos necessários para modelos de branding ou gerenciados centralmente, imagens de base (máquinas virtuais, contêineres) e muito mais. Novamente, os catálogos privados e o Container Registry são serviços típicos.
• Torem recursos escassos disponíveis para mais usuários. Às vezes, um tipo de recurso só está disponível em quantidade limitada. Ao compartilhar, mais aplicativos podem se beneficiar dele. Isso pode exigir limitador de taxa.

Compartilhamento de recursos de segurança

Muitas vezes, a segurança é gerenciada em um nível corporativo com regras de empresa em vigor. Por isso, a aplicação é gerida centralmente, também. Isso ainda é verdade com as cargas de trabalho se movimentando para ambientes em nuvem. O compartilhamento de recursos está na base da segurança de gerenciamento centralmente, bem como na avaliação e na aplicação da conformidade.

O diagrama acima mostra os seguintes cenários:

1. Instâncias de Object Storage e Databases for MongoDB em Conta A e Conta B utilizam chaves de criptografia gerenciadas na Conta Principal em Key Protect.
2. Security and Compliance Center na Conta Principal governa os recursos em todas as três contas (veja linhas pretas acima).
3. As instâncias de IBM Cloud Activity Tracker Event Routing na Conta A e na Conta B direcionam os registros de auditoria para IBM Cloud Logs na Conta principal (veja as linhas azuis acima). O IBM Cloud Logs é configurado para manter os registros de auditoria para atender aos requisitos corporativos e de análise.

O compartilhamento pode ser entre contas em um ambiente IBM Cloud Enterprise ou sem uma organização corporativa formal.

Compartilhamento de recursos de rede

Projetar e desenvolver apps nativos em nuvem em um contexto corporativo muitas vezes envolve a coordenação em relação a recursos de rede como faixas de endereço e sub-redes, nomes de domínio e roteamento do tráfego. As diferentes contas e seus aplicativos e ambientes de cálculo precisam se encaixar na rede e na sua estrutura. Isso requer compartilhamento de recursos de rede.

1. O serviço Transit Gateway é usado para interconectar ambientes VPC e infraestrutura clássica através das três contas.
2. Cada conta possui uma instância DNS Services para gerenciar nomes de domínio privado. As instâncias estão conectadas para compartilhar zonas DNS.

Implementar o compartilhamento de recursos

Como dito na introdução, é prática comum o acesso a serviços fora da conta de um (cloud). Dependendo do nível de integração, existem diferentes formas de autorizar o acesso ao serviço e implementar a autenticação. Essas opções disponíveis são discutidas abaixo.

Autorização de serviço para serviço

Uma abordagem integrada mais rígida para um serviço acessando outro é para estabelecer autorizações de serviço para serviço(autorizaçãos2s). Você cria uma política do IBM Cloud Identity and Access Management (IAM) que autoriza um serviço de origem a acessar um serviço de destino. Como a autenticação é realizada através da identificação do serviço de origem solicitante de acesso, não são necessárias credenciais na forma de senhas ou chaves API. Tanto a autenticação quanto a autorização são manipuladas automaticamente por causa da política IAM criada.

Autorizações de contas cruzadas

O IAM suporta estabelecer autorizações de serviço para serviço entre um serviço de origem em outra conta IBM Cloud e um alvo na atual. Portanto, ele permite o compartilhamento de recursos através de contas, criando uma política de autorização do IAM. Tais políticas podem ser criadas de muitas maneiras, incluindo no console do navegador como mostrado abaixo, utilizando a CLI ou executando o código Terraform.

Nos exemplos a seguir, uma instância específica Object Storage na instância de origem é concedida a função Reader para aquela instância identificada Key Protect na conta corrente.

A seguir mostra o código Terraform para criar um recurso com a mesma política de autorização do 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"
}

A mesma política de autorização pode ser criada usando o comando IBM Cloud CLI com o 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

O console, o provedor Terraform e o CLI todos usam a API de gerenciamento de políticas IAM para criar a política.

Como uma próxima etapa, com a política de autorização em vigor, um balde de armazenamento criptografado usando uma chave raiz Key Protect poderá então ser criado. O seguinte mostra o código do Terraform utilizando o recurso ibm_cos_bucket. O atributo key_protect mantém o CRN da chave raiz.

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"
}

Você pode encontrar mais exemplos no repositório GitHub cross-account-resource-sharing.

Autorizações típicas de serviço para serviço

Uma dependência em um serviço de gerenciamento de chaves (KMS) como Key Protect e Hyper Protect Crypto Services é típico para soluções baseadas em nuvem. Uma instância do KMS mantém as chaves raiz para criptografia gerenciada pelo cliente. A maioria dos serviços suporta chaves de criptografia controladas pelo cliente. Em vez de cloud-object-storage (Object Storage) no exemplo acima, muitos outros serviços podem usar uma instância de KMS compartilhada através de contas.

Outros serviços típicos (de destino) para autorização de serviço a serviço e os candidatos para compartilhamento de recursos incluem:

• Object Storage: Vários serviços requerem ou são capazes de armazenar dados e arquivos de log em um balde de armazenamento. Isso inclui o arquivamento de logs de acesso e de dados de monitoramento Outros serviços precisam acessar depósitos para executar análise de dados. E mais uma categoria de serviços precisa de acesso para assinar notificações de mudança para acionar a execução de ações.
• Event Notifications: Para empurrar para fora informações sobre eventos para assinantes, instâncias de serviço precisam acessar uma instância Event Notifications.
• Secrets Manager: Este serviço armazena e fornece a outros serviços chaves de API IAM, certificados SSL/TLS e outros segredos. Daí, os serviços dependentes (fonte) precisam acessar Secrets Manager.
• Cloud Internet Services (CIS): Ela gerencia nomes de domínio e outros dados de rede e, portanto, pode ser usada para, por exemplo, validação de certificado.
• IBM Cloud Logs Routing e IBM Cloud Activity Tracker Event Routing: precisa de acesso de serviço a alvos como IBM Cloud Logs.

Observe que a lista acima não está completa.

Resumo

Acessar recursos em contas diferentes, até mesmo compartilhar recursos é prática comum. Há vários casos de uso em que os usuários se beneficiam do compartilhamento de recursos. Eles foram discutidos na visão geral. Uma combinação de identidade de usuário e senha ou uma chave API para acessar um recurso muitas vezes serve como autenticação. O acesso pode ser escoado para um conjunto de privilégios, por ex., apenas permitindo o acesso de leitura ou algumas outras ações restritas. Às vezes, esses tipos de credenciais podem ser criadas e gerenciadas pelo recurso de acesso como um aplicativo ou ambiente de cálculo ("ligação de serviço"). Uma integração ainda mais apertada o que não requer credenciais é o conceito de IBM Cloud autorização de serviço para serviço. O recurso de acesso (origem) e o recurso acessado (destino) são identificados por suas propriedades (autenticação) e uma função de acesso é atribuída (autorização). Tal relacionamento pode ser mesmo estabelecido através de limites de contas. Isso permite um simples de configurar, mas ainda o compartilhamento de recursos de contas cruzadas seguras.

Você pode encontrar exemplos de código sobre como configurar o compartilhamento de recursos para alguns desses serviços no repositório GitHub cross-account-resource-sharing.

Recursos relacionados

O documento a seguir fornece detalhes sobre alguns cenários de conta cruzada:

• IBM Cloud as chaves de API para um usuário podem ter um escopo através de várias contas

Posts do Blog relacionados ao compartilhamento de recursos através de várias contas:

• Terraform multi-account setup para IBM Cloud
• Dicas e Tricks para Usar a CLI IBM Cloud discute IBMCLOUD_HOME que pode ser usado para trabalhar com várias contas da CLI.