About cookies on this site Our websites require some cookies to function properly (required). In addition, other cookies may be used with your consent to analyze site usage, improve the user experience and for advertising. For more information, please review your options. By visiting our website, you agree to our processing of information as described in IBM’sprivacy statement. To provide a smooth navigation, your cookie preferences will be shared across the IBM web domains listed here.
Article
Building secure and scalable Cloud infrastructure with IBM Cloud Projects
Learn how to use IBM Cloud Projects and Deployable Architectures to automate secure, scalable infrastructure deployment using Infrastructure as Code
On this page
Building cloud infrastructure that meets security and scalability requirements can be challenging. While these needs are critical in regulated industries such as financial services, healthcare, and telecom, they are now essential for all enterprise solutions to protect against cybersecurity threats.
Using an Infrastructure-as-Code (IaC) approach brings the benefits of traditional software development practices such as version control, change tracking, and peer reviews to cloud resource management.
IBM Cloud offers tools to help streamline this process. Cloud Projects with Deployable Architectures (DAs) make it easier and faster to deploy secure, compliant infrastructure by using pre-built and validated templates.
When combined with Enterprise accounts, IBM Cloud Projects support strong environment isolation, access control, and secure deployment processes to reduce risk and prepare your cloud solutions for future growth.
Secure architecture principles
When using the Infrastructure as Code (IaC) approach for designing and deploying cloud solutions, it is important to follow general secure architecture principles. These are similar to the guidelines in the IBM Cloud Framework for Financial Services, but they apply to any enterprise solution, not just those in regulated industries. Following these principles helps build a strong and secure foundation for your infrastructure and development lifecycle.
Security-by-design with Enterprise accounts
Using designated sub-accounts within an IBM Cloud Enterprise account helps keep environments isolated, making it easier to manage resources, access, and costs.
Each sub-account includes a foundation layer of cloud resources that is set up using standardized Deployable Architectures (DAs) to support essential auditing and access control from the start.
Separation of duties
IBM Cloud IAM should be used to give developers and administrators only the access they need.
In production accounts, privileged access (such as Manager or Administrator roles) is limited to automated deployment processes. Operators get restricted access for daily tasks and can be temporarily granted higher permissions through break-glass procedures. This reduces the risk of accidental or malicious changes in production environments.
Infrastructure-as-Code with audit and change controls
Cloud resources are deployed using Cloud Projects and automation, with changes managed through a CI/CD process.
All configurations are stored in source code repositories and changes are tracked and reviewed before deployment. Using standard DevOps tools such as GitHub helps reduce errors, especially when moving changes from staging to production.
Separation of production and non-production environments
Non-production environments should follow the same security principles as production. However, there must be a clear separation between production and non-production accounts, resources, and change control processes to ensure proper management and security.
Enterprise account structure
The IBM Cloud Enterprise account framework helps you meet security, compliance, governance, and scalability needs when building cloud solutions, whether for a whole company, a single solution, or a managed infrastructure.
The enterprise account framework in IBM Cloud helps you meet key requirements such as security, compliance, governance, and scalability, whether you are building a solution for a company, a single project, or a managed infrastructure service. The Enterprise Architecture white paper offers detailed guidance on how to design and manage account structures for different use cases.
Setting up an enterprise account with even a few sub-accounts can make managing Infrastructure-as-Code (IaC) easier, even for just one solution.
We recommend creating the following accounts under your enterprise account to support an effective IaC process. The following order reflects the typical setup sequence, for example, the Central Admin account is created first to enable early use of Deployable Architectures, followed by the Shared Services Hub, which hosts common services such as Key Management used across accounts.
Recommended account structure
Enterprise Root account
top-level account used to manage all sub-accounts.
No solution resources are deployed here.
Central Admin account
Deploys foundation and security components (for example, Activity Tracker) to other accounts as soon as they are created.
Hosts a private catalog for custom Deployable Architectures (DAs).
Used to validate custom DAs.
Runs the Security and Compliance Center to scan resources in target accounts.
IaC developers and operators use this account to manage and deploy Cloud Projects, with separate administrators for staging and production environments
Shared services hub
A production-level account that hosts shared services for all other accounts (for example, Key Management Service such as Key Protect or interconnectivity components such as DirectLink).
Some services like DirectLink may be manually provisioned, but changes are rare.
This account is often set up before others to provide essential shared services (such as encryption) needed by dependent accounts.
Operators are granted temporary elevated access when needed.
Infrastructure-as-Code (IaC) Sandbox
Used to test Cloud Project setups and configurations safely, without affecting Central Admin.
Supports development and testing of custom Deployable Architectures (DAs).
Can be used to provision temporary resources for evaluation or testing.
While business workloads can be tested here, frequent infrastructure changes can make it unstable for full workload testing.
Best suited for testing deployment automation, with actual workload testing recommended in the Staging environment.
IaC developers have elevated access to manage and experiment with resources freely.
Staging Core
Used to test solution infrastructure before production deployment.
Resources are deployed from Central Admin using Cloud Projects and DAs.
Mirrors the production environment to ensure accurate testing.
May have limited access to shared services hub (for example, DirectLink) for integration testing.
Should remain stable, with changes following proper change control and testing procedures.
IaC developers and operators do not have admin permissions to avoid manual or out-of-cycle changes.
Production Core
Hosts final production solution resources.
Resources are deployed from Central Admin after successful testing in Staging.
IaC developers and operators do not have admin permissions.
Break-glass procedures are in place for emergency privileged access.
Figure. Account groups, individual accounts, and Cloud Projects used for resource deployment
Using IBM Cloud Projects and Deployable Architectures
IBM Cloud Projects offer a structured way to manage the full lifecycle of Infrastructure as Code (IaC). Combined with Deployable Architectures (DAs) from public, community, or private catalogs, they enable high levels of automation for deploying and managing cloud resources.
Each project can include multiple configurations, each tied to a specific DA and a target account. In a Central Admin model, Cloud Projects are managed in a central account and used to deploy to various accounts across the enterprise. You can also use this setup within a single account if needed.
Recommendations
Create separate projects for deploying solution resources to Staging and Production. This allows for better access control and separation of environments.
Set up each account with a foundation layer of resources (for example, Activity Tracker and Cloud Logs) for audit and security. These resources are typically stable and do not change often.
Use separate projects to manage these foundation resources, so they remain isolated from more frequently updated solution components.
For detailed guidance, refer to the Best practices for organizing and managing project documentation.
Foundation Layer
Includes audit and security components such as Activity Tracker, Cloud Logs, and their storage targets.
Sets up common access control groups used across all environments.
Deployed to every account to ensure consistent security and audit coverage.
Built using the VPC Landing Zone DA with overrides, or the newer IBM Cloud Essential Security and Observability Services stack DA, plus a custom DA for access groups.
Solution Layer
Contains solution-specific infrastructure and configurations using DAs from public, community, or private catalogs, such as:
VSI on VPC Landing Zone with custom overrides
Custom DAs for business-specific needs
Each environment (for example, Staging and Production) uses its own configuration for the same DAs, allowing environment-specific customization.
Figure. Cloud Projects with Deployable Architectures and their deployment targets
If you are using custom DAs from a private catalog to deploy your solution, it is recommended to create a separate project just for validating those DAs before using them in production.
Lessons learned: Managing accounts, projects, and access
Throughout the process of implementing Infrastructure as Code on IBM Cloud using Enterprise Accounts and Cloud Projects, we identified a few key practices that helped improve security, manageability, and efficiency. These lessons can help guide similar efforts, whether for a single solution or across a broader enterprise.
Use functional IDs for account creation: Create new accounts using a functional ID (not a personal user ID) to avoid tying ownership to one person. This ID should not be used for day-to-day activities afterward.
Set up projects and trusted profiles: For each new account, create a matching project in the Central Admin account. Then, set up a trusted profile with elevated permissions in the new account and link it to the project. This avoids using API keys and simplifies secure deployments.
Access control for IaC developers: In Staging and Production Core accounts, restrict IaC developers to Viewer or Reader roles. This ensures changes go through Projects and Deployable Architectures. Create IAM Access Groups scoped to specific Cloud Projects with Operator roles. This limits who can deploy to production.
VPC landing zone DAs from the IBM Cloud Public Catalog: The VPC Landing Zone Deployable Architectures (DAs) from the IBM Cloud public catalog such as VPC Landing Zone and VSI on VPC Landing Zone are highly flexible and powerful. They allow you to build complex solution architectures without writing Terraform code from scratch.
In most cases, you will need to use the
overrideparameter to customize these DAs for your solution, such as configuring VPC networks, security groups, and access control lists. While managing overrides can become complex, it is still generally faster and more reliable than developing and testing custom Terraform code.Custom Deployable Architectures (DAs): While the public and community catalogs in IBM Cloud offer a wide range of Deployable Architectures (DAs), you might still need to create custom DAs for specific use cases.
To build custom DAs, you can use Terraform modules from the IBM Terraform Modules (TIM) collection. However, you'll need to create your own wrapper modules to integrate your Terraform code into a private catalog.
For detailed guidance, refer to the custom DA development section in the Running Secure Workload solution guide.
CI/CD process for Cloud Projects: Currently, there is no official template available to fully automate the Infrastructure-as-Code (IaC) lifecycle, from source control (for example, Git) to deployment using Cloud Projects.
To fill this gap, we used custom shell scripts to process JSON configuration files and update Cloud Project configurations. While this approach works, it requires manual setup. We hope IBM Cloud will offer a standard CI/CD toolchain integration for Cloud Projects in the near future.
Conclusion
Setting up a well-structured enterprise account and using Cloud Projects in IBM Cloud is key to successfully implementing Infrastructure-as-Code (IaC) for your cloud solutions.
By following the principles and best practices shared in this article, you can build a strong foundation that supports security, compliance, governance, and scalability, right from the start.