Is it possible at the same time to give development teams the freedom to innovate while still including best practices, information security, and cost-effectiveness in the mix?
Many organizations are currently thinking about migrating to cloud services or managing their existing operations in the cloud the right way. The speed of innovation and development relative to the required governance considerations are often at odds with each other. Such considerations include security considerations, infrastructure visibility, and shared distributed services to manage your organization’s cloud usage effectively.
The fundamental problem arises from the fact that flexibility and speed of development are most often in the interest of developers. At the same time, governance is the responsibility of the IT department or similar parts of an organization. Newer concepts like DevOps or DevSecOps combine these aspects to some extent, but in practice, the organization has to consider both aspects.
The need for governance and the speed of innovation are often two opposing goals. At a practical level, deploying new resources in the cloud should be seamless, so that an individual developer or developer organization can deploy new things to the cloud at the speed at which it is possible in the cloud — in practice, in seconds or minutes. Similarly, it must also be possible to disable resources quickly after testing, without affecting any of the production loads.
However, it is good to have guardrails that protect the organization and the developers themselves from making accidental or deliberate bad choices, which can have high cost or security implications. Yet, this need for governance should not stifle the speed of development and innovation that the cloud-based environment allows. Somehow organization has to find the balance between governance and speed at which changes are allowed to cloud-based environments. At a practical level, changes to the cloud development environment cannot usually be a manual process where someone outside the development team does this; for example, on a ticket basis. The process needs to be fast and automated as far as possible.
Is it possible in real-life to take into account the operational and security aspects of governance, compliance, and cost objectives when compared to agility, response to change, and self-service goals? The following example uses ready-made tooling from Amazon Web Services (AWS).
Foundations for Guardrails
Different cloud service providers handle the organization structure in projects in very different ways when it comes to organizing workloads in a meaningful way, often due to security or financial concerns. If an organization selects AWS as the implementation platform, it may come as a surprise that you often use accounts as the mechanism to organize the workloads.
Examples of breakdowns are setting up accounts based on projects (Project A and Project B), environments (production, testing, or development), or even separate accounts for development personnel. An organization may choose to create a sandbox environment for each developer as a separate account. Creating separate accounts for these purposes is often a bit counter-intuitive if you are accustomed to setting up a single account for a company and then providing the necessary resources underneath it.
The multi-account strategy used by AWS can be challenging to implement correctly right from the start if you are not familiar with the topic. How should you plan your account structure to allow for speed of development while still taking into account security barriers that protect the developer and the organization from harm? Also, the implementation should take into account aspects that are common throughout the organization. Such cross-cutting aspects include information security, visibility through the organization, auditing, logging, and user and access management. It is possible to take these principles into account at a later stage, but the easiest thing to do is to get it right when you set up the cloud organization structure.
Guardrails as a Service: AWS Control Tower
For new accounts, AWS can use the Control Tower service, which allows you to create an account structure using best practice advice. Control Tower helps you create the necessary accounts and allow you to manage them.
In practice, Control Tower creates at least the following structures:
- The necessary organizational hierarchy for managing AWS accounts and users
- Features for self-service creation of new AWS accounts
- Policies that automatically link new AWS accounts to the organizational hierarchy and ensure that the AWS accounts comply with the organization’s governance specifications
- User and license management across all AWS accounts using Single Sign-On (SSO) for your organization
- Ability to configure separate, secure AWS accounts that automatically collect all log and audit trail data from the AWS environments used by your organization
- Centralized management of network configurations of AWS accounts used by the organization
- Dashboard view of your organization’s AWS accounts and resources
- Central logging and monitoring of services with the possibility to set up centralized notifications for certain types of events.
But, there is a catch to this. At the time of writing this article, you cannot use the AWS Control Tower service with existing accounts that are part of an AWS Organization. AWS may enable importing existing accounts and organization structures to the Control Tower service in the future. But for now, the usage of Control Tower in practice requires new accounts and account structures for AWS.
Pieces that Control Tower uses underneath are standard AWS services such as Organizations, Single Sign-On, Service Catalog, and CloudFormation, which can also be used separately on already existing accounts. With this approach, you won’t get the out-of-the-box experience you get with AWS Control Tower, and you have to build these facilities and setup yourself. Though, even if you have existing accounts, testing out the Control Tower functionality might be beneficial as the Infrastructure as Code (IaC) produced by Control Tower may provide insights into the “AWS way” of building these structures. An organization looking for a complete IaC approach may want to consider using the AWS Landing Zone directly rather than Control Tower.
Control Tower is a viable option in situations where you create new accounts in AWS or if you migrate existing accounts into new accounts. If your organization is a brand new AWS user, then the structure created through Control Tower provides a solid foundation for managing AWS accounts. When deployed, Control Tower creates a robust infrastructure for your organization. It provides reasonable assumptions about the guardrails, the rules that govern your accounts, and directly allows you to share permissions from a central directory across accounts.
Once you take Control Tower into use, you can create new accounts for a specific part of an organization with a self-service account vending machine with a few mouse clicks. You can let each developer in your organization create a secure and managed AWS account for themselves on a self-service basis.
Control Tower Deployment
Deploying Control Tower begins by defining your organization’s necessary information through the AWS Admin Console. The Control Tower then creates several structures for you to use.
The most important of these is probably the account structure, which has shared accounts for logging and auditing, and a master account that owns the Control Tower. The picture below also has a few additional accounts created for various purposes. Please note that I’ve obfuscated the account descriptions and identifications in the picture.
Control Tower also creates the foundations for an organizational structure that can each have a different number of guardrails as needed. Parts of organization structure, including Core and Root, are used by shared accounts created by the Control Tower for logging and auditing purposes.
An organization may deploy guardrails differently in different parts of the organization, depending on what type of guardrails you require for the specific organization part. For instance, you may wish to get a notification, if individual sub-accounts do not have 2-Step Verification (MFA) enabled.
Certain guardrails in Control Tower are enabled by default for all accounts as they are considered mandatory for all accounts. An excellent example of such a guardrail is the assurance that a sub-account cannot remove auditing of configuration changes to that account. Behaviour indication for the guardrail in turn indicates whether the given guardrail is preventive and thus disallows a certain action, or detects and informs of situations that should be present for the account in question.
An organization may create new sub-accounts easily the Account Factory product that Control Tower creates in the Service Catalog product. This product for creating new accounts can be made available to those persons in the organization that need the ability to create governed accounts in the organization.
Creating a managed sub-account using AWS best practices is very easy with the account vending machine. Just fill in a couple of nuggets of information, and Control Tower does the rest.
I’d recommend checking out the Control Tower if you are thinking about management and organization for accounts in the AWS environment. Even if you already have multiple AWS accounts, studying the way AWS approaches this is valuable. Examining the structures produced by Control Tower gives you a good idea of how to enable productivity and speed while taking into guardrails that need be in place across the organization.