Learn About Deploying Terraform Stacks for E-Business Suite and Cloud Manager

Deploy these stacks in the given order. However, they are modular enough that you can pick and choose the stacks you want to use as long as you already have created resources that can fulfill the E-Business Suite requirements.

These stacks are available in Oracle Cloud Marketplace. You will be directed to Oracle Cloud Infrastructure Resource Manager to deploy these stacks. OCI Resource Manager is a native Terraform engine in OCI, which provides a graphical interface to create, run, and manage your Terraform.

About Deploying the IAM Stack

This Terraform stack creates the necessary Identity Resources for EBS. It creates compartments for Security, Network, EBS workload, Cloud Manager, and each EBS environment category. Each compartment comes with at least one group and policy to facilitate simple Role-Based Access Control (RBAC). You must manually add users to these groups or map them from a federated identity provider.

Run this stack if you want to deploy EBS to a new tenancy. If you are deploying to an existing tenancy with a sufficient IAM structure, you don't have to deploy this stack.

Enter the following variables when running the IAM stack:

  • IAM and credential admin groups: Use default values. Creates two tenancy wide groups. One has permissions to manage other user's credentials and the other has permissions over most other Identity actions.
  • Create general policy: Use default values. Creates permissions for any user to inspect and read certain resources across the tenancy. Required to run the EBS Cloud Manager stack without administrator permissions.
  • Landing Zone prefix: Same for every EBS stack and any other apps deployed within this landing zone.
  • Parent compartment: This can be your root compartment or another existing compartment in your tenancy.
  • EBS workload prefix: Remains the same for every EBS stack.
  • EBS workload environment categories: List every category (or set) of EBS environments you plan to create. You can type your category names directly into the prompt box and then select Add from the drop-down menu to add it to the list.
  • Advanced options: You can additionally customize network and security compartment names or use an existing compartment instead of creating a new one. You can also customize vault, keys, and secrets.

Note:

If you want to use an existing vault or key, you must specify the compartment it is located in as the existing security compartment.

About Manually Configuring Identity

Some Identity actions are not possible in Terraform, and Oracle doesn't recommend managing certain other actions through Terraform for security purposes.

A tenancy administrator or IAM administrator can manually configure these resources in the console. Follow these steps:

  1. Create the necessary user accounts.
  2. Map the user accounts to the appropriate IAM groups.

Create User Accounts

You can create different types of accounts in OCI. If you already have a SAML 2.0 compliant identity provider, you can federate that provider with your OCI tenancy. From there, you can map external federated groups directly to OCI IAM groups. If you don't already have an external identity provider, you can create users directly into either the OCI default identity domain or a new one. However, you require direct IAM users for users in the default identity domain to ensure that the EBS Cloud Manager user permissions work properly inside the EBS Cloud Manager application.

Map Users to IAM Groups

You must determine which users will be responsible for which OCI resource types. There can be one user who is responsible for multiple resource types, or multiple users who are responsible for a single resource type. A tenancy administrator must first add the IAM admins to their groups. IAM admins can then add the rest of the users to their respective groups. They must create accounts for any users who don't have an account and also add the users to the relevant groups.

The following list maps the users to their respective groups:

  • Map IAM users to the Network Users, Security Users, and Application Administrator/IDCS Administrator groups.
  • Map Security Users to the Security Administrators and Network Users groups.
  • Map Network Users to the Network Administrators and Security Users groups.
  • Map each EBS environment category (including the Cloud Manager user) to the Network Users and Security Users groups, the EBS environment admin groups that they manage, as well as the EBS CM admin group.

    Note:

    A user must be a direct OCI IAM user and not a federated user.

About Deploying the Network Stack

This Terraform stack creates a VCN and the public and private subnets necessary for the EBS Cloud Manager. You must run one copy of this stack per each EBS environment category you defined in the IAM stack.

Enter the following variables when running the Network stack:

  • Security compartment: Find the security compartment created/used in the IAM stack from the prepopulated list or supply its OCID. This variable allows the stack to automatically find all the required information from previous stacks that were stored as secrets.
  • Workload identity secret: Select the secret corresponding to the general EBS workload in name format: identity-"lz prefix"-"workload prefix".
  • EBS workload prefix: Remains the same for every EBS stack.
  • Advanced options: Allows you to additionally customize the secrets consumed and created.
  • Create VCN: You have the option to create a new VCN or use an existing VCN. For subsequent deployments of EBS network environment categories, you must select the existing VCN created or used in the initial deployment.
    • True
      • VCN CIDR: Specify the CIDR block range to use for your VCN.
    • False
      • Network compartment: Specify the compartment where your VCN resides.
      • Existing VCN: Find the existing VCN from the prepopulated list or supply its OCID.
  • Environment category identity secret: Select the secret corresponding to the specific EBS workload environment category in name format: identity-"lz prefix"-"workload prefix"-"environment name".

    Note:

    If you need a network for additional environment categories, you must deploy another copy of the Network stack.

The following table lists the subnet creation variables, subnet configuration access gateway, CIDR variables, and when to use them:

Subnet Creation Variable When to use? Subnet Configuration and Gateway Access CIDR Variables*
Create Cloud Manager subnets or Select existing Cloud Manager subnet Create subnets once in the first network environment stack created. In subsequent environments, select the existing Cloud Manager subnet created by the first stack. Private Subnets with NAT gateway access.

Note:

You can optionally make the Load Balancer subnet public, which will then use Public Subnet with an Internet Gateway access. This is not the recommended process.
  • Cloud Manager Load Balancer subnet CIDR
  • Cloud Manager Instance subnet CIDR
Create subnets for an EBS environment (app and database) Every EBS environment category subnet configuration and gateway access Private subnets with NAT gateway access
  • Application tier subnet CIDR
  • Database tier subnet CIDR
Create default Load balancer tier subnet Use by default to provide access to EBS over private networks Private Subnets with NAT gateway access Load balancer subnet CIDR
Create external load balancer and application tier subnets Only in EBS environment categories that need to provide user access over the internet

Public LB subnet with internet access.

Private App subnet with NAT Gateway access.

  • External Load Balancer subnet CIDR
  • External App subnet CIDR
Create File Storage subnet or Select existing File Storage subnet Only use if your EBS implementation uses shared file storage. Create it once in the first network environment stack. In subsequent stacks, select the existing subnet you created in the first stack. Private Subnets with NAT gateway access File Storage subnet CIDR
Create Bastion subnet Once in the first network environment stack created When the Use Bastion Service variable is true, the subnet is private. Otherwise it is public with Internet Gateway access. Bastion Subnet CIDR
Additional ebs subnets When creating new Cloud Manager or File Storage subnets, specify any additional EBS subnets in the current VCN that you already have, or that you plan to create in different stacks. Adds additional routing rules to Cloud Manager and File Storage subnets
  • Additional application tier subnet CIDRs
  • Additional database tier subnet CIDRs

Note:

The private or default LB is it's own option.

Footnotes

* Specify a unique CIDR block range for the each subnet that falls within your VCN CIDR range and doesn't conflict with any other subnet's CIDR range.

Use Bastion Service

You can optionally use the Bastion service.

  • True: Provisions the subnet as Private along with the Bastion service.
    • Bastion allow list: List of external IP ranges in CIDR notation that can make inbound SSH connections.
    • Bastion TTL limit: Maximum time allowed for an SSH connection to remain active, measured in seconds. Allowed values are between 30 minutes (1800 seconds) and 3 hours (10800 seconds).
  • False: Provisions the subnet as Public but doesn't provision a traditional Bastion virtual machine.

About Deploying the Cloud Manager Stack

This Terraform stack creates the Cloud Manager (CM) VM and Load Balancer as well as CM app bootstrapping.

Global Design Decisions

You'll have to make decisions and enter several variables when running the IAM stack.

  • Environment category identity secret: Select the secret corresponding to the specific environment category of EBS workload in name format: identity-"lz prefix"-"workload prefix"-"environment name". The environment you select will be used to create the default network profile.
  • Security compartment: Find the security compartment created or used in the IAM stack from the prepopulated list or supply its OCID. This variable allows the stack to automatically find all the required information from previous stacks that were stored as Secrets.
  • Advanced options: Allows you to additionally customize the secrets consumed and created.

DNS and Certificate Configuration

DNS and Certificates are recommended but optional.

  • Cloud Manager CA cert (optional): Provide the signed certificate authority chain used to generate your Cloud Manager certificate as a file.
  • Cloud Manager key cert: Provide the private key certificate file you generated to use for EBS Cloud Manager.
  • Cloud Manager Public cert: Provide the public certificate chain used to validate your private certificate as a file.

    Note:

    If you don't provide the private key certificate, a certificate will be generated for you using openSSL and the provided hostname.
  • Server host for EBS Cloud Manager login URL: Enter a hostname for the EBS Cloud Manager web portal. The input format should be myebscm.example.com and match your DNS entry, signed certificate, and Confidential Application. The EBS Cloud Manager login URL will be https://myebscm.example.com:443.
    • CM CA certificate
    • CM key certificate
    • CM public certificate

Create a Confidential Application

An application administrator must first register EBS CM as a Confidential Application using the OCI Console to manage E-Business Suite using Cloud Manager. This allows users to authenticate and authorize access to the Cloud Manager using their OCI account.

Before creating the Confidential Application, you must know the URL that you plan to use for the EBS Cloud Manager. This URL must match the hostname in your DNS record and signed certificate.

You must use the client ID and secret provided when running the Cloud Manager stack.

IDCS or Identity Domain Configuration

  • IDCS Client ID: ID of Confidential Application for EBS Cloud Manager that was registered when configuring the identity.
  • IDCS Client Secret: Secret of the Confidential Application for EBS Cloud Manager that you registered when configuring the identity.
  • IDCS Client Tenant: ID of the IDCS or Identity Domain tenant. This can be seen as part of the URL in your browser's address bar, after the // and before identity.oraclecloud.com. It begins with the characters idcs-, followed by a string of numbers and letters in the format idcs-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.

EBS CM Admin

  • Cloud Manager Admin User OCID: By default, this stack will use the account of the user running this stack as the initial Cloud Manager admin. Optionally, you can make another user the initial admin by supplying their OCID here. This admin account must be a local non-federated IAM user.
  • Cloud Manager Admin User Private API key: By default, a new API key is created and associated with the chosen Cloud Manager admin account. Optionally, you can enter an already associated private API key.

Cloud Manager Virtual Machine

  • EBS Cloud Manager shape: Select a shape from the list for the EBS Cloud Manager VM. Oracle recommends the Standard2.x and Standard.E2.x shapes.
  • SSH key: Public SSH key used to access the Cloud Manager using the CLI.
  • EBS Cloud Manager Availability Domain: Select your Availability Domain from the list.
  • CM Password: The password for the EBS CM Admin.

Note:

The password should be minimum 8 characters, one uppercase letter, one lowercase letter, one number, one special character (#?!@$%^&*-). The password is used by the EBS Cloud Manager administrator to connect to the Cloud Manager instance, and then run subsequent scripts. The initial default password is WElcome##12345. Oracle recommends that you change the password with a value that meets the password requirements listed in this note.