Oracle Cloud Infrastructure Resources and Services
Oracle Cloud Infrastructure (OCI) provides various resources and services that enable you to govern your resources. Learn about OCI services and how they can enable your organization to implement a governance model.
Resources
Oracle Cloud Infrastructure (OCI) enables you to organize your resources and implement governance in your organization. Learn about the physical and logical organization of OCI resources and services.
Region
OCI is physically hosted in geographical regions and availability domains. A region is a localized geographic area, and an availability domain is one or more data centers located within a region.
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
A region is composed of one or more availability domains. OCI resources are either region-specific, such as a virtual cloud network, or availability domain specific, such as a compute instance.
Availability Domain
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
When you configure cloud services, use multiple availability domains to ensure high availability and to protect against resource failure. Be aware that some resources must be created within the same availability domain, such as an instance and the storage volume attached to it.
Fault Domain
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.
For example, a hardware failure or Compute hardware maintenance event that affects one fault domain does not affect instances in other fault domains.
Identifying Resources
A fundamental concept to identify OCI resources is the OCID (Oracle Cloud Identifier). It is a unique identifier that identifies resources in an Oracle Cloud Infrastructure (OCI) service that contain metadata about the resources. The resource can be a user or a group, or an instance or a service. The resource which is an instance of a service or a principal, is a component of the full OCID of a particular resource.
OCI uses the OCID to identify and enforce policies on resources when you implement governance in your organization. The following shows the OCID syntax and its components:
Oracle Cloud Infrastructure provides the following services that enable you to create, organize, and administer your cloud resources.
ocid1.<RESOURCE TYPE>.<REALM>.[REGION][.FUTURE USE].<UNIQUE
ID>- OCID1: The literal string indicating the version of the OCID.
- Resource Type: The type of resource such as instance, VCN, user, or group.
- Realm: A realm is a set of regions that share entities such as oc1 for commercial realm, oc2 for government cloud, oc3 for the federal government.
- Region: The geographical region of residence of the resource is in such as phx, iad.
- Future Use: Specifies if the resources are reserved for future use.
- Unique ID: The unique portion of the ID.
Tenancy
A tenancy is a secure and isolated partition that Oracle sets up within Oracle Cloud when you sign up for Oracle Cloud Infrastructure. You can create, organize, and administer your resources in Oracle Cloud within your tenancy. A tenancy is synonymous with a company or organization. Usually, a company will have a single tenancy and reflect its organizational structure within that tenancy. A single tenancy is usually associated with a single subscription, and a single subscription usually only has one tenancy.
Each resource within a Tenancy Structure in the tenancy belongs to a compartment (with few exceptions) which allows the resources to be logically grouped and managed to conform to the defined governance model. A resource is provisioned in the tenancy related to IaaS, PaaS, and infrastructure components, but not limited to Virtual Cloud Networks (VCNs), subnets, security, and routing rules.
Most of the core resources belong to a compartment within the tenancy. However, there are core resources which are global and live outside of compartments.
Compartments
Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.
Well-designed compartments enable your organization to do the following:
- Control access by compartments to enforce segregation of duties and control access based on function such as networking resources or databases
- Delegate administrative privileges to compartment administrators to manage their respective resources
- Develop a charge-back model by departments based on their respective compartments
- Define quotas and budges based on compartments
Service Limits
When you sign up for OCI, a set of service limits are configured for your tenancy. The service limit is the quota or allowance set on a resource. For example, your tenancy maybe allowed a maximum number of Data Science Service instances. Every resource has a defined limit and scope. The limits initially set in the tenancy are based upon a combination of resources purchased in the Bill of Materials and values determined as defaults. The scope of service limits is either regional or availability domain-specific allowing for additional flexibility. These limits may be increased for you automatically based on your OCI resource usage and account standing.
Budgets
You can specify a budget to set soft limits on your OCI spending. You can also set alerts on your budget to notify you when usage exceeds your budget. You can view all your budgets and spending in a single place using the OCI console.
Compartment Quotas
Compartment quotas give tenancy and compartment administrators better control over how resources are consumed in OCI. Quotas enable administrators to easily allocate resources to compartments using the console. Compartment quotas provide a powerful mechanism to manage your spending in OCI tenancies.
Logging
- Audit logs: Logs related to events emitted by the Audit service.
- Service logs: Logs emitted by individual services such as API Gateway, Events, Functions, Load Balancing, Object Storage, and VCN flow logs.
- Custom logs: Logs that contain diagnostic information from custom applications, other cloud providers, or an on-premises environment.
Log Groups
Logical containers for organizing logs that are used to define/limit access to logs to a limited group of users. You can create separate log groups based on the sensitivity of log data.
For example, create three log groups: Security, Network, and Application.
- Then for each log group, create OCI IAM policies to provide admin users access to read blogs from log groups.
- Allow group SecOps to read log-content in compartment logging where:
target.loggroup.id=’ocid1.loggroup.oc1.<OCIRegion>..<SecurityLogGroupUniqueID>
Logging Analytics
A cloud solution in OCI that lets you index, enrich, aggregate, explore, search, analyze, correlate, visualize, and monitor all log data from your applications and system infrastructure.
Logging Analytics provides multiple ways of gaining operational insights from your logs.
- Use the log explorer UI
- Aggregate log information into dashboards
- Utilize the APIs to ingest and analyze data
- Integrate with other OCI services
Cloud Guard
Description of the illustration cloud-guard-detector-recipe.png
You can use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.
Detector Recipe
A set of rules/checks to identify potential security problems. Oracle provides some baseline detector recipes for services like object storage buckets, compute instances, VCN instances, IAM users and groups, load balancers, security lists, and network security groups. You can't update the recipe rule for Oracle-managed recipes. However, you can clone Oracle-managed recipes and create new recipes called user-managed detector recipes.
Recipes for Rules to Detect Problems
- Oracle-managed recipes
- User-managed recipes
- Configuration detector recipes
- Public bucket
- Instance has a public IP address
- LB SSL certificate is about to expire
- Activity detector recipes
- User added to a group
- Compute instance deleted
Configuration Detector recipes check resource configurations. For example, check if the storage bucket is public or if there is a NAT gateway or Internet Gateway created in a VCN. Other detector recipes detect activity like creating a dynamic group or adding a VNIC to the VM.
Responder Recipe
A set of rules to either remediate the problem detected or send a notification requesting action. The default responder recipe does not give an option to remediate every problem. You can, however, address that by invoking functions from events. You take corrective measures or remediate the problem from the OCI function.
Like detector recipes, there are Oracle-managed responder recipes and customer-managed responder recipes. Customer-managed responder recipes are a clone of Oracle-managed recipes where you can disable some of the predefined responder rules.
Target
A target defines the scope of what Cloud Guard should check. It includes a list of compartments. When you add a compartment as a target, the Cloud Guard checks all the sub-compartments as well. Targets are defined where compartments, detector recipes, and responder recipes tie together.
Tagging
Tags contain metadata, key-value pairs, that are attached to resources and define their attributes such as usage, cost, or ownership.
Tag Basics
Tag namespace (only applicable to defined tags)
Tag namespace is a container for your tags. It consists of a name and zero or more tag key definitions. Tag namespace is unique across the tenancy.
Tag key
The name you use to refer to the tag. Tag keys are unique across the namespace.
Tag value type
It specifies the data type allowed for the value. There are two supported data types: String and a list of strings.
Tag value
It is the value that the user applies to the tags. Some tags have predefined values. Users must choose one value from the list of values for other tags.
A resource, which is an instance of a service on a compartment, can have one or more tags. Tags assigned to a compartment are assigned to all the resources in the compartment.
There are two ways to assign tags to resources.
Defined Tags
Predefined tags where administrators manage the metadata are more commonly used. For example, to create resource metadata to manage resources or collect data, you can use defined tags. There are three types of defined tags based on their usage and how values are assigned.
-
Tags with predefined values
You can create a list of values and associate that list with a tag key definition. When users apply the tag to a resource, they must select a value from the list of predefined values. Use lists of predefined values to impose limits on the values that users can apply to tags.
-
Cost tracking tags
Tags that are used when setting budgets to manage cost of resource usage.
-
Tag defaults
You can define default tags that will be applied to all resources when they are created in a specific compartment. Setting up tag defaults ensures that the appropriate tags are applied at resource creation without requiring the user who is creating the resource to have access to the tag namespaces. Use tag variables to efficiently create tag defaults for resources created in a compartment. For example:$(iam.principal.name}, $(iam.principal.type}, ${oci.datetime}
Free-form tags
User-defined unmanaged metadata applied to resources during the life cycle of a resource.