How MSPs Can Deliver IT-as-a-Service with Better Governance

 Sanjay Basu


As a solutions architect, I often support partners who deliver managed IT services to their end customers. Similarly, I work with large enterprises who manage IT for multiple business units. One of the most frequent requests I get is for best practices on how to align Oracle Cloud Infrastructure solutions and Identity and Access Management (IAM) policies with business-specific governance use cases. For enterprise customers, this means having better control over usage costs across multiple business units. For managed service providers (MSPs), this involves having better cost governance over the IT environments that they manage for end customers in their Oracle Cloud Infrastructure tenancy.

This post is structured like a case study, in which an example enterprise customer, ACME CORP's Central IT team, faces the following business challenge: How do they enable their departmental IT stakeholders, and the operators within those departments, to have the autonomy to use their relevant Oracle Cloud Infrastructure services while still maintaining control over cost and usage? The post shows how this can be accomplished by using nested compartments and budgets. It also demonstrates how to maintain a separation of duties by delegating the management of security lists to the departmental application teams while enabling Central IT network admins to retain control over all networking components. This is particularly applicable for any application team using a CI/CD pipeline for their projects, automating the deployment and updating of subnets and security lists as part of their infrastructure as code (IaC) pipeline.

The Business Challenge

ACME CORP is a large enterprise company with a Central IT team and departmental IT teams that reside within the Finance and HR departments.

The Central IT team manages the base cloud infrastructure for the company, and they manage IAM for all cloud services. Additionally, the Central IT Network Admin and Database (DB) Admin teams manage networking and database systems for the Finance and HR departments.

The Finance and HR Departmental IT teams teams each comprise their own applications and database groups. The Finance and HR Applications groups are responsible for application deployment and should be able to manage the relevant infrastructure services for their specific projects. Therefore, Central IT needs to grant the departmental applications groups the ability to manage their own application workloads and the associated virtual infrastructure services, including application load balancers and security lists.

However, Central IT wants more centralized control over the company's databases. They plan to grant the HR Database group the ability to read HR databases only, and they will grant the Finance Database group the ability to read and write financial databases.

Finally, Central IT needs to grant an additional group, a team of Accountants, the ability to control costs and usage by the Finance and HR teams through the use of budgets.

 


 

The Solution

Now let's establish the right identities and access so that the Central IT team and the departmental IT teams have access to their cloud resources.

Create Groups of Users Based on Role

First, we create the following groups, which map to the preceding roles:

  • NetworkAdmin
  • DatabaseAdmin
  • FinApplication
  • HRApplication
  • FinDBuser
  • HRDBuser
  • Accountants

Align Compartment Structure with Organizational Hierarchy

Next, we implement the necessary compartment structure to separate resources by department. This solution has three levels of nested compartments with associated cloud infrastructure assets, as shown in the following image:

First-Level Compartment

In ACME CORP's tenancy, a root compartment is automatically created for Central IT, in which they can create policies to manage access to resources in all underlying compartments.

Second-Level Compartments

Under the root compartment are the following child compartments. The following screenshot shows what the compartment nesting would look like in the console.

  • Central_IT_Network: For shared networking service elements, including FastConnect, internet gateway, IPSec termination points, and DNS
  • Finance: Contains the VCN for finance projects and applications
  • HR: Contains the VCN for HR projects and applications

When you click into these compartments, you can create the VCNs for each one.

Because the Central_IT_Network compartment does the VCN transit routing for the company, it's configured to contain the following components:

  • Dynamic routing gateways for IPSec
  • Internet gateway having public IPs
  • FastConnect
  • Load balancers for public-facing web servers
  • DNS database
  • Local peering to VCN_ACME_FIN and VCN_ACME_HR

The Finance compartment houses its own private network for their department, named VCN_ACME_FIN, and contains the following components:

  • Load balancers for Finance intranet servers
  • Active domain controllers for Finance
  • File Storage for Finance users
  • Object Storage for Finance users
  • Databases for Finance users

The HR compartment has its own network, VCN_ACME_HR, along with the following components:

  • Load balancers for HR intranet servers
  • Object Storage for HR users
  • Databases for HR users

Third-Level Compartments

Nested under the Finance compartment are the Project A and Project B compartments. Each project can house resources leveraged by specific applications.

Nested under the HR compartment are similar compartments for HR Project A and Project B.

Subnets and Security Lists

For Finance Project A, we created two subnets under VCN_ACME_FIN (in the Finance compartment), but because we want to enable the CI/CD pipeline to automatically update and deploy application-specific security lists, we created the security lists in the Project A compartment.

We replicated the same creation and placement for Finance Project B.

The following image shows how we created the security list in the Finance Project A compartment:

We performed the same type of subnet and security list placements for HR Project A and Project B.

Now that we've isolated resources by compartment for department and project usage, we'll create budgets to control spending.

Creating Budgets to Control Spending

Next we establish permissions for the Accountants group (see the "Policies" section), enabling them to administer budgets and proactively control spending for each department. For example, they can create a budget for the Finance compartment that would also cover Finance Projects A and B. The total limit of monthly spend could be set at US$1,200, and a threshold set at 50 percent for an email notification to be sent out to the right teams to take action when spending reaches 50 percent of budget. For more information about creating a budget, see Managing Budgets.

Policies

We created the following policies for each group and compartment.

Policies applied on the ACME_CORP root compartment

  • Policy to enable the DatabaseAdmin group to manage databases across all compartments in the tenancy:
    • ALLOW GROUP DATABASEADMIN TO MANAGE DATABASE-FAMILY IN TENANCY   
  • Policy to enable the NetworkAdmin group belonging to Central IT to have administrative rights over all network resources in the Central_IT_Network compartment:
    • ALLOW GROUP NetworkAdmin TO MANAGE VIRTUAL-NETWORK-FAMILY IN COMPARTMENT CENTRAL_IT_NETWORK

Policies applied on the Finance compartment

  • Policy to enable FinDBuser to have read and write rights on Financial database:
    • ALLOW GROUP FINDBUSER TO USE DATABASE-FAMILY IN COMPARTMENT FINANCE
  • Policy to enable the Finance application teams, including automated CI/CD systems, to manage virtual machines, object storage, and security lists in their respective project compartments:
    • ALLOW GROUP FINAPPLICATION TO MANAGE OBJECT-FAMILY IN COMPARTMENT FINANCE
    • ALLOW GROUP FINAPPLICATION TO MANAGE SECURITY-LISTS IN COMPARTMENT PROJECT A
    • ALLOW GROUP FINAPPLICATION TO MANAGE SECURITY-LISTS IN COMPARTMENT PROJECT B
    • ALLOW GROUP FINAPPLICATION TO MANAGE INSTANCE-FAMILY IN COMPARTMENT PROJECT A
    • ALLOW GROUP FINAPPLICATION TO MANAGE INSTANCE-FAMILY IN COMPARTMENT PROJECT B

Policies applied on the HR compartment

  • Policy to enable HRDBuser to have read only rights on Financial database:
    • ALLOW GROUP HRDBUSER TO READ DATABASE-FAMILY IN COMPARTMENT FINANCE
  • Policy to enable the HR application teams, including automated CI/CD systems, to manage virtual machines, object storage, and security lists in their respective project compartments:
    • ALLOW GROUP HRAPPLICATION TO MANAGE OBJECT-FAMILY IN COMPARTMENT HR
    • ALLOW GROUP HRAPPLICATION TO MANAGE SECURITY-LISTS IN COMPARTMENT PROJECT A
    • ALLOW GROUP HRAPPLICATION TO MANAGE SECURITY-LISTS IN COMPARTMENT PROJECT B
    • ALLOW GROUP HRAPPLICATION TO MANAGE INSTANCE-FAMILY IN COMPARTMENT PROJECT A
    • ALLOW GROUP HRAPPLICATION TO MANAGE INSTANCE-FAMILY IN COMPARTMENT PROJECT B

Policy to enable budget management is applied on the ACME_CORP compartment

  • ALLOW GROUP ACCOUNTANTS TO MANAGE USAGE-BUDGETS IN TENANCY

The following image explains the syntax used for policies:

Conclusion

An MSP or central IT organization can deliver services across multiple organizations and departments, even when all are placed within the same tenancy. You can separate resources while still maintaining governance and control by leveraging nested compartments, assigning policies at the appropriate level of the nested compartments, and configuring a budget to limit resource usage and maintain logical isolation and requisite access controls.

Resources

Comments

Post a Comment

Popular posts from this blog

OCI Object Storage: Copy Objects Across Tenancies Within a Region

The Legal Rights of an Algorithm

Religious Perspectives on Artificial Intelligence: My views