Resource sharing across accounts

Objectives

• Understand the benefits of sharing resources across accounts
• Learn about different techniques to share resources across accounts

Resource sharing overview

It is not unusual to find multiple applications access and use the same resource or parts of it. One example is when applications and compute environments have to live on the same corporate network. Another scenario is that security logs are collected in central storage. In a microservice architecture, it requires us to configure services to access and use external resources. In turn, the shared resources must authorize access, and the network between them is configured to support such collaboration, but not more.

Some typical use cases of resource sharing are:

• Central management of security-related infrastructure. Monitor security from a dedicated account, and aggregate security logs in a single place. Manage all encryption keys in central key management systems (KMS).
• Coordination of network addresses and subnets. Applications and compute environments need to fit into the same network and require sharing of address ranges and domain names.
• Central management of resources for disaster recovery, including backup services like IBM Cloud Backup for Classic. Applications and their services may be designed for high availability, but additional centrally organized resources might be available to fall back to in the worst case. This includes holding multiple resource copies available worldwide, e.g., stored in replicated Object Storage buckets.
• Control costs by sharing more expensive services where possible. Not every development project needs to have all services deployed as dedicated instances. Often, it is enough to share service instances - within accounts or across. Even for production environments, service instances might be shared depending on their cost/value factor and technical feasibility. This can be organized by restricting available services in an account by utilizing private catalogs and restricting the public catalog, then centrally providing instances of restricted services.
• Central management of resources on a corporate level or for a business unit. This could be assets needed for branding or centrally managed templates, base images (virtual machines, containers), and more. Again, private catalogs and the Container Registry are typical services.
• Make scarce resources available to more users. Sometimes, a resource type is only available in limited quantity. By sharing, more applications can benefit from it. This may require rate limiting.

Sharing of security resources

Often, security is managed on a corporate level with company-wide rules in place. Therefore, enforcement is managed centrally, too. This is still true with workloads moving to cloud environments. Resource sharing is at the foundation of centrally managing security as well as assessing and enforcing compliance.

The above diagram shows the following scenarios:

1. Instances of Object Storage and Databases for MongoDB in Account A and Account B utilize encryption keys managed in the Main Account in Key Protect.
2. Security and Compliance Center in the Main Account governs resources in all three accounts (see black lines above).
3. Instances of IBM Cloud Activity Tracker Event Routing in Account A and Account B direct audit logs to IBM Cloud Logs in the Main Account (see blue lines above). The IBM Cloud Logs is configured to persist the audit logs to meet analysis and corporate requirements.

Sharing can be between accounts in an IBM Cloud Enterprise environment or without a formal enterprise organization.

Sharing of network resources

Designing and developing cloud native apps in an enterprise context often involves coordinating regarding network resources like address ranges and subnets, domain names, and routing of traffic. The different accounts and their applications and compute environments need to fit into the network and its structure. This requires sharing of network resources.

1. The Transit Gateway service is used to interconnect VPC environments and classic infrastructure across the three accounts.
2. Each account has a DNS Services instance to manage private domain names. The instances are connected to share DNS zones.

Implementing resource sharing

As stated in the introduction, it is common practice to access services outside the one (cloud) account. Depending on the level of integration, there are different ways to authorize service access and implement authentication. Those available options are discussed below.

Service-to-service authorization

A tighter integrated approach for one service accessing another one is to establish service-to-service authorizations (s2s authorization). You create an IBM Cloud Identity and Access Management (IAM) policy that authorizes a source service to access a target service. Because the authentication is accomplished by identifying the source service requesting access, no credentials in the form of passwords or API keys are needed. Both authentication and authorization are handled automatically because of the created IAM policy.

Cross-account authorizations

IAM supports establishing service-to-service authorizations between a source service in another IBM Cloud account and a target in the current one. Therefore, it allows sharing resources across accounts by creating an IAM authorization policy. Such policies can be created in many ways, including in the browser console as shown below, utilizing the CLI or by executing Terraform code.

In the following examples, a specific Object Storage instance in the source account is granted the Reader role for that identified Key Protect instance in the current account.

The following shows the Terraform code to create a resource with the same IAM authorization policy:

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

The same authorization policy can be created using the IBM Cloud CLI with the iam service-policy-create command:

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

The console, the Terraform provider and the CLI all use the IAM policy management API to create the policy.

As a next step, with the authorization policy in place, an encrypted storage bucket using a Key Protect root key could then be created. The following shows the Terraform code utilizing the resource ibm_cos_bucket. The attribute key_protect holds the CRN of the root key.

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

You can find more examples in the GitHub repository cross-account-resource-sharing.

Typical service-to-service authorizations

A dependency on a key management service (KMS) like Key Protect and Hyper Protect Crypto Services is typical for cloud-based solutions. A KMS instance holds the root keys for customer-managed encryption. Most services support customer-controlled encryption keys. Instead of cloud-object-storage (Object Storage) in the example above, many other services can use a KMS instance shared across accounts.

Other typical (target) services for service-to-service authorization and candidates for resource sharing include:

• Object Storage: Several services require or are able to store data and log files in a storage bucket. This includes the archiving of access logs and monitoring data. Other services need to access buckets to perform data analysis. And yet another category of services need access to subscribe to change notifications to trigger the execution of actions.
• Event Notifications: To push out information about events to subscribers, service instances need to access an Event Notifications instance.
• Secrets Manager: This service stores and provides to other services IAM API keys, SSL/TLS certificates, and other secrets. Hence, the dependent (source) services need to access Secrets Manager.
• Cloud Internet Services (CIS): It manages domain names and other network data and, therefore, can be used for, e.g., certificate validation.
• IBM Cloud Logs Routing and IBM Cloud Activity Tracker Event Routing: needs service access to targets like IBM Cloud Logs.

Note that the above list is not complete.

Summary

Accessing resources in different accounts, even sharing resources is common practice. There are several use cases where users benefit from resource sharing. They were discussed in the overview. A combination of user identity and password or an API key to access a resource often serves as authentication. Access can be scoped to a set of privileges, e.g., only allowing read access or some other restricted actions. Sometimes, these type of credentials can be created and managed by the accessing resource like an application or compute environment ("service binding"). An even tighter integration which does not require credentials is the concept of IBM Cloud service-to-service authorization. The accessing resource (source) and the accessed resource (target) are identified by their properties (authentication) and an access role is assigned (authorization). Such a relationship can be even established across account boundaries. This allows for a simple to configure, but yet secure cross-account resource sharing.

You can find code examples on how to set up resource sharing for some of these service in the GitHub repository cross-account-resource-sharing.

Related resources

The following document provides details on some cross-account scenarios:

• IBM Cloud API keys for a user may have a scope across multiple accounts

Blog posts related to sharing resource across multiple accounts:

• Terraform multi-account setup for IBM Cloud
• Tips and Tricks for Using the IBM Cloud CLI discusses IBMCLOUD_HOME which can be used to work with multiple accounts from the CLI.