Addressing Basic Configuration Issues

This topic lists procedures to address common configuration issues that affect the security of your cloud resources.

Block Volume

Block volume detached from instance

Issue: Ensure that only Oracle Cloud Infrastructure administrators can detach block volumes from instances.

Basics: When you detach a block volume it decouples the volume from its associated instance, affecting the data available to the instance. This could impact data availability from business-critical data to the successful completion of scheduled volume backups. To minimize loss of data due to inadvertent volume detachments by an authorized user or malicious volume detachments you should restrict the VOLUME_ATTACHMENT_DELETE permission to administrators.

To prevent detachment of block volumes:

The following policy allows the group VolumeUsers to manage volumes and volume attachments except for detaching volumes:

Allow group VolumeUsers to manage volumes in tenancy
Allow group VolumeUsers to manage volume-attachments in tenancy
    where request.permission!='VOLUME_ATTACHMENT_DELETE'			

This change prevents VolumeUsers from detaching volumes from instances.

More information:

Compute

Instance created based on unapproved custom image

Issue: An instance was created from a custom image that is unsupported in your environment.

Basics: When users create instances they can select from Oracle-provided images, boot volumes from terminated instances, or custom images. Custom images represent a wide variety of images which can include images that aren't approved for your environment. If you use tags in your Oracle Cloud Infrastructure tenancy to identify approved images, verify whether the image the instance is based on is an approved image and terminate the instance if necessary.

To verify the tags for the image the instance was created from:

The following procedure is for the Oracle Cloud Infrastructure Console.

  1. Open the navigation menu. Under Core Infrastructure, go to Compute and click Instances.
  2. Click the instance you're interested in.
  3. Click the Image link to view the source image.
  4. Click the Tags tab to view the tags applied to this image.

If the custom image does not have an approved tag, and the instance needs to be terminated, see Terminating an Instance.

More information:

IAM

Member of the Administrators group used API keys

Issue: A user who is a member of the Administrators group accessed resources using an API key.

Basics:

  • API keys are credentials used to grant programmatic access to Oracle Cloud Infrastructure.
  • For security and governance reasons, users should only have access to resources they need to interact with.

  • For individuals who are members of the Administrators group who also need access to resources through the API, create another user in IAM to which you attach the API keys. Grant the user with the API keys permissions to only the resources they need to interact with programmatically.

To create a user, group, and policy with limited permissions:

The following set of procedures shows you how to set up an example user with limited permissions. In this example, the user needs to be able to launch instances in a specific compartment.

The following procedure is for the Oracle Cloud Infrastructure Console.

Create a User
  1. Open the navigation menu. Under Governance and Administration, go to Identity and click Users.
  2. Click Create User.
  3. In the New User dialog:

    • Name: Enter a unique name or email address for the new user. The value will be the user's login to the Console and must be unique across all other users in your tenancy.
    • Description: Enter a description (required).
  4. Click Create User.
Create a Group

Next, create the group ("InstanceLaunchers" ) that you will create the policy for.

  1. Open the navigation menu. Under Governance and Administration, go to Identity and click Groups.
  2. Click Create Group.
  3. In the Create Group dialog:

    • Name: Enter a unique name for your group, for example, "InstanceLaunchers".

      Note that the name cannot contain spaces.

    • Description: Enter a description (required).
  4. Click Create Group.
Create a Policy

In this example, the policy grants members of the group InstanceLaunchers permissions to launch instances in a specific compartment (CompartmentA).

  1. Open the navigation menu. Under Governance and Administration, go to Identity and click Policies.
  2. Click Create Policy.
  3. Enter a unique Name for your policy, for example, "InstanceLaunchersPolicy".

    Note that the name cannot contain spaces.

  4. Enter a Description (required), for example, "Grants users permission to launch instances in CompartmentA".
  5. Enter the following Statement:
    Allow group InstanceLaunchers to manage instance-family in compartment CompartmentA

    This statement grants members of the InstanceLaunchers group permissions to launch and manage instances in the compartment called CompartmentA.

  6. Click Create Policy.
Add the User to the Group
  1. Open the navigation menu. Under Governance and Administration, go to Identity and click Users.
  2. In the Users list, find the user and click the name.
  3. On the user detail page, click Groups (on the left side of the page). The list of groups that the user belongs to is displayed.

  4. Click Add User to Group.
  5. From the Groups list, select InstanceLaunchers.
  6. Click Add.
Upload an API signing key for the user

The following procedure works for a regular user or an administrator. Administrators can upload an API key for either another user or themselves.

Important

The API key must be an RSA key in PEM format (minimum 2048 bits). The PEM format looks something like this:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoTFqF...
...
-----END PUBLIC KEY——

For more information about generating a public PEM key, see Required Keys and OCIDs.

  1. View the user's details:
    • If you're uploading an API key for yourself:

      Open the Profile menu (User menu icon) and click User Settings.

    • If you're an administrator uploading an API key for another user: In the Console, click Identity, and then click Users. Locate the user in the list, and then click the user's name to view the details.
  2. Click Add Public Key.
  3. Paste the key's value into the window and click Add.

    The key is added and its fingerprint is displayed (example fingerprint: d1:b2:32:53:d3:5f:cf:68:2d:6f:8b:5f:77:8f:07:13).

More information:

Policy grants broad permissions

Issue: A policy grants full management permissions for at least one service in a compartment or in the tenancy.

Basics:

  • Access to resources is controlled through policies. A policy is a document that specifies who can access which Oracle Cloud Infrastructure resources that your company has, and how. A policy simply allows a group  to work in certain ways with specific types of resources  in a particular compartment .
  • For security and governance reasons, users should only have access to resources they need.
  • Consider carefully the access level a user needs. Policy language provides a default set of verbs (manage, use, read, inspect) that allow you to easily scope users' permissions to a set of common tasks. For example, if a user needs to be able to update resources, but does not need to create or delete them, grant them the use permission, rather than the manage permission.
  • The policy language is designed to let you write simple statements involving only verbs and resource-types, without having to state the permissions in the statement. For more fine-grained access control, you can use conditions combined with permissions or API operations to reduce the scope of access granted by a particular verb.

  • Wherever possible, scope access to the specific compartments a user needs access to, rather than scoping it to the full tenancy.

Tips for writing least-privilege policies:

Scope the policy to a compartment instead of the tenancy

Each policy consists of one or more policy statements that follow a basic syntax. Where possible, scope policies to compartments, rather than to the tenancy. For example, update a policy like this:

Allow group <group_name> to <verb><resource-type> in tenancy

to include just the compartments needed:

Allow group <group_name> to <verb><resource-type> in compartment <compartment_name>

If the user needs access to multiple compartments, create a policy statement for each compartment. It is then easy to remove access to individual compartments, if necessary.

Scope permissions to those required to perform a job function

Oracle defines the possible verbs you can use in your policies. Here's a summary of the verbs, from least amount of access to the most:

Verb Types of Access Covered Target User
inspect Ability to list resources, without access to any confidential information or user-specified metadata that may be part of that resource. Third-party auditors
read Includes inspect plus the ability to get user-specified metadata and the actual resource itself. Internal auditors
use Includes read plus the ability to work with existing resources (the actions vary by resource type). In general, this verb does not include the ability to create or delete that type of resource. Day-to-day end users of resources
manage Includes all permissions for the resource. Administrators

Users who don't need to create or delete resources generally don't need manage permissions. If you have a policy like

Allow group <group_name> to manage <resource-type> in compartment <compartment_name>

but the user will never create or delete the resource-type, consider rewriting the policy to

Allow group <group_name> to use <resource-type> in compartment <compartment_name>

The Policy Reference includes details of the specific resource-types for each service, and which verb + resource-type combination gives access to which API operations.

For fine-grained access control, scope access using conditions and API operations

In a policy statement, you can use conditions combined with permissions or API operations to reduce the scope of access granted by a particular verb.

For example, let's say you want group XYZ to be able to list, get, create, or update groups (change their description), but not delete them. To list, get, create, and update groups, you need a policy with manage groups as the verb and resource-type. According to the table in Details for Verbs + Resource-Type Combinations, the permissions covered are:

  • GROUP_INSPECT
  • GROUP_UPDATE
  • GROUP_CREATE
  • GROUP_DELETE

To restrict access to only the desired permissions, you could add a condition that explicitly states the permissions you want to allow:

Allow group XYZ to manage groups in tenancy

 where any {request.permission='GROUP_INSPECT',
            request.permission='GROUP_CREATE',
            request.permission='GROUP_UPDATE'}

An alternative would be a policy that allows all permissions except GROUP_DELETE:

Allow group XYZ to manage groups in tenancy where request.permission != 'GROUP_DELETE'

Another alternative would be to write a condition based on the specific API operations. Notice that according to the table in Permissions Required for Each API Operation, both ListGroups and GetGroup require only the GROUP_INSPECT permission. Here's the policy:

Allow group XYZ to manage groups in tenancy

 where any {request.operation='ListGroups',  
            request.operation='GetGroup',
            request.operation='CreateGroup',
            request.operation='UpdateGroup'}

It can be beneficial to use permissions instead of API operations in conditions. In the future, if a new API operation is added that requires one of the permissions listed in the permissions-based policy above, that policy will already control XYZ group's access to that new API operation.

But notice that you can further scope a user's access to a permission by also specifying a condition based on API operation. For example, you could give a user access to GROUP_INSPECT, but then only to ListGroups.

Allow group XYZ to manage groups in tenancy

 where all {request.permission='GROUP_INSPECT',  
            request.operation='ListGroups'}

More information:

API signing keys over 90 days old

Issue: A user's API signing keys are older than 90 days. Oracle recommends that you rotate API keys at least every 90 days.

Basics:

  • API keys are credentials used to grant programmatic access to Oracle Cloud Infrastructure.
  • It is a security engineering best practice and compliance requirement to rotate API keys regularly, every 90 days or less.

  • Ensure that you test the new keys before you deactivate the old keys.

To generate and upload new API keys:

The following procedure is for the Oracle Cloud Infrastructure Console.

Generate new API keys
You can use the following OpenSSL commands to generate the key pair in the required PEM format. If you're using Windows, you'll need to install Git Bash for Windows and run the commands with that tool.
  1. If you haven't already, create a .oci directory to store the credentials:

    
    mkdir ~/.oci
                        
  2. Generate the private key with one of the following commands.

    • Recommended: To generate the key, encrypted with a passphrase you provide when prompted:

      openssl genrsa -out ~/.oci/oci_api_key.pem -aes128 2048 
                                  

      Note: For Windows, you may need to insert -passout stdin to be prompted for a passphrase. The prompt will just be the blinking cursor, with no text.

      openssl genrsa -out ~/.oci/oci_api_key.pem -aes128 -passout stdin 2048
                                  
    • To generate the key with no passphrase:

      openssl genrsa -out ~/.oci/oci_api_key.pem 2048
                                  
  3. Ensure that only you can read the private key file:

    chmod go-rwx ~/.oci/oci_api_key.pem
                        
  4. Generate the public key:

    openssl rsa -pubout -in ~/.oci/oci_api_key.pem -out ~/.oci/oci_api_key_public.pem
                        

    Note: For Windows, if you generated the private key with a passphrase, you may need to insert -passin stdin to be prompted for the passphrase. The prompt will just be the blinking cursor, with no text.

    openssl rsa -pubout -in ~/.oci/oci_api_key.pem -out ~/.oci/oci_api_key_public.pem -passin stdin
                        
  5. Copy the contents of the public key to the clipboard using pbcopy, xclip or a similar tool (you'll need to paste the value into the Console later). For example:

    cat ~/.oci/oci_api_key_public.pem | pbcopy
                        
Your API requests will be signed with your private key, and Oracle will use the public key to verify the authenticity of the request. You must upload the public key to IAM (instructions below).
Get the key's fingerprint

You can get the key's fingerprint with the following OpenSSL command. If you're using Windows, you'll need to install Git Bash for Windows and run the command with that tool.

openssl rsa -pubout -outform DER -in ~/.oci/oci_api_key.pem | openssl md5 -c

When you upload the public key in the Console, the fingerprint is also automatically displayed there. It looks something like this: 12:34:56:78:90:ab:cd:ef:12:34:56:78:90:ab:cd:ef

Upload the API signing key for the user
You can upload the PEM public key in the Console, located at https://console.us-ashburn-1.oraclecloud.com. If you don't have a login and password for the Console, contact an administrator.
  1. Open the Console, and sign in.
  2. View the details for the user who will be calling the API with the key pair:

    • If you're signed in as this user, click your username in the top-right corner of the Console, and then click User Settings.
    • If you're an administrator doing this for another user, instead click Identity, click Users, and then select the user from the list.
  3. Click Add Public Key.
  4. Paste the contents of the PEM public key in the dialog box and click Add.
The key's fingerprint is displayed (for example, 12:34:56:78:90:ab:cd:ef:12:34:56:78:90:ab:cd:ef). Notice that after you've uploaded your first public key, you can also use the UploadApiKey API operation to upload additional keys. You can have up to three API key pairs per user. In an API request, you specify the key's fingerprint to indicate which key you're using to sign the request.
Test the new key

Test the key in a sample API call against Oracle Cloud Infrastructure.

Delete the old key
The following procedure works for a regular user or an administrator. Administrators can delete an API key for either another user or themselves.
  1. View the user's details:
    • If you're deleting an API key for yourself:

      Open the Profile menu (User menu icon) and click User Settings.

    • If you're an administrator deleting an API key for another user: In the Console, click Identity, and then click Users. Locate the user in the list, and then click the user's name to view the details.
  2. For the API key you want to delete, click Delete.
  3. Confirm when prompted.
The API key is no longer valid for sending API requests.

More information:

Tenancy administrator privilege grant to an IAM group

Issue: A group other than the Administrators group has been granted administrator privileges.

Basics:

  • Granting the tenancy administrator privilege (manage all-resources in tenancy) to a group enables the members to have full access to all resources in the tenancy.
  • This high-privilege entitlement must be controlled and restricted to only the users who need it to perform their job function.
  • Verify with the Oracle Cloud Infrastructure administrator that this entitlement grant was sanctioned and that the membership of the group remains valid after the grant of the administrator privilege.
  • Rather than create an alternative group with administrator privileges, consider instead adding users needing administrator privileges to the default Administrators group.

To resolve this issue:

Add users who need administrator privileges to the Administrators group:

  1. Open the navigation menu. Under Governance and Administration, go to Identity and click Groups.
  2. In the Groups list, click Administrators.
  3. Click Add User to Group.
  4. In the Add User to Group dialog, select the user from the User list.
  5. Click Add User.

Remove the policy or policy statement that grants the (non-Administrators) group administration privileges.

  1. Open the navigation menu. Under Governance and Administration, go to Identity and click Policies. A list of the policies in the compartment you're viewing is displayed.

    If you don’t see the one you're looking for, verify that you’re viewing the correct compartment (select from the list on the left side of the page).

  2. Click the policy you want to update.

    The policy's details and statements are displayed.

  3. Find the statement that grants administrator privileges to the group. This policy will look like:

    Allow group <group_name> to manage all-resources in tenancy
    

    Click the the Actions icon (three dots) and then click Delete.

  4. If the policy has no other statements, you can delete the policy by clicking Delete next to the policy name.

More information:

Networking: VCN, Load Balancers, and DNS

No ingress rules in security lists

Issue: A VCN's security lists have no ingress rules. This means that the instances in the VCN can't receive incoming traffic.

Basics:

  • Security lists provide stateful and stateless firewall capability to control network access to your instances.
  • A security list is configured at the subnet level and enforced at the instance level.
  • You can associate multiple security lists with a subnet. A packet is allowed if it matches any rule in any of the security lists used by the subnet.
  • If there are no ingress (inbound) rules in any of the subnet's security lists, no traffic is allowed to the instances in that subnet.
  • For defense in depth, ingress security list rules should state a specific known source and not an open source (0.0.0.0/0).
  • You can configure an exception in Oracle CASB Cloud Service to reduce alerts from exempted security lists.

To add an ingress rule to an existing security list:

The following procedure is for the Oracle Cloud Infrastructure Console.

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  2. Confirm you're viewing the compartment that contains the cloud network you're interested in.
  3. Click the cloud network you're interested in.
  4. Click Security Lists.
  5. Click the security list you're interested in.
  6. Click Edit All Rules.
  7. Add at least one ingress rule:

    1. In the Allow Rules for Ingress section, click + Rule.
    2. Choose whether it's a stateful or stateless rule (see Stateful Versus Stateless Rules). By default, rules are stateful unless you specify otherwise.
    3. Enter the source CIDR. Typical CIDRs you might specify in a rule are the CIDR block for your on-premises network or a particular subnet. If you're setting up a security list rule to allow traffic with a service gateway , instead see Task 3: (Optional) Update security rules.
    4. Select the protocol (for example, TCP, UDP, ICMP, "All protocols", and so on).
    5. Enter further details depending on the protocol:
      • If you chose TCP or UDP, enter a source port range and destination port range. You can enter "All" to cover all ports. If you want to allow a specific port, enter the port number (for example, 22 for SSH or 3389 for RDP) or a port range (for example, 20-22).
      • If you chose ICMP, you can enter "All" to cover all types and codes. If you want to allow a specific ICMP type, enter the type and an optional code separated by a comma (for example, 3,4). If the type has multiple codes you want to allow, create a separate rule for each code.
  8. When you're done, click Save Security List Rules.

This change enables ingress access from the source CIDR block listed in the rule. Add additional rules if you want to allow ingress from other known sources.

More information:

Security list allows traffic from any IP address (open source)

Issue: A security list has at least one rule with an open source (0.0.0.0/0). This means that traffic could come from any source and is not controlled.

Basics:

  • Security lists provide stateful and stateless firewall capability to control network access to your instances.
  • A security list is configured at the subnet level and enforced at the instance level.
  • You can associate multiple security lists with a subnet. A packet is allowed if it matches any rule in any of the security lists used by the subnet.
  • If there are no ingress (inbound) rules in any of the subnet's security lists, no traffic is allowed to the instances in that subnet.
  • For defense in depth, ingress security list rules should state a specific known source and not an open source (0.0.0.0/0).
  • You can configure an exception in Oracle CASB Cloud Service to reduce alerts from exempted security lists.

To change the source of a security list rule:

The following procedure is for the Oracle Cloud Infrastructure Console.

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  2. Confirm you're viewing the compartment that contains the cloud network you're interested in.
  3. Click the cloud network you're interested in.
  4. Click Security Lists.
  5. Click the security list you're interested in.
  6. Click Edit All Rules.
  7. Locate the rule that lists 0.0.0.0/0 as the source CIDR.
  8. For that rule, change 0.0.0.0/0 to the CIDR block of a known source.
  9. Click Save Security List Rules.

This change restricts ingress so packets are allowed only from a specific CIDR block. Add additional rules if you want to allow ingress from other known sources.

More information:

Security list allows traffic to sensitive ports

Issue: A security list has at least one rule that enables access to a sensitive port.

Basics:

  • Security lists provide stateful and stateless firewall capability to control network access to your instances.
  • A security list is configured at the subnet level and enforced at the instance level.
  • You can associate multiple security lists with a subnet. A packet is allowed if it matches any rule in any of the security lists used by the subnet.
  • If there are no ingress (inbound) rules in any of the subnet's security lists, no traffic is allowed to the instances in that subnet.
  • For defense in depth, ingress security list rules should state a specific known source and not an open source (0.0.0.0/0).
  • You can configure an exception in Oracle CASB Cloud Service to reduce alerts from exempted security lists.

Recommendation: Update the subnet's security list to enable access to instances through SSH (TCP port 22) or RDP (TCP port 3389) on a temporary, as-needed basis, and only from authorized CIDR blocks (not 0.0.0.0/0). To perform instance health checks, update the security list to allow ICMP pings.

To change an existing security list:

The following procedure is for the Oracle Cloud Infrastructure Console.

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  2. Confirm you're viewing the compartment that contains the cloud network you're interested in.
  3. Click the cloud network you're interested in.
  4. Click Security Lists.
  5. Click the security list you're interested in.
  6. Click Edit All Rules.
  7. Make one or more of these changes:
    • Delete an existing rule by clicking the X next to the rule.
    • Change an existing rule in the list. For example: change the source from 0.0.0.0/0 to the CIDR block of a known source.
    • Add a new rule by clicking + Rule and entering values for the new rule.
  8. Click Save Security List Rules.

More information:

Internet gateway attached to VCN

Issue: A VCN has an internet gateway. The gateway must be authorized to be attached to the VCN and must not unintentionally expose resources to the internet.

Basics:

  • Gateways provide external connectivity to hosts in a VCN. For example: an internet gateway enables direct internet connectivity for instances that are in a public subnet and have a public IP address. A dynamic routing gateway (DRG) enables connectivity with the on-premises network over an IPSec VPN or FastConnect.
  • To enable traffic through the internet gateway from a particular subnet in the VCN, there must be a rule in the subnet's route table that lists the internet gateway as a route target. To delete the internet gateway from the VCN, you must first delete any route rules that specify the internet gateway as the target.
  • You can configure an exception in Oracle CASB Cloud Service to reduce alerts from exempted VCNs.

To remove an internet gateway from a VCN:

Prerequisite: Ensure that there are no route rules that specify the internet gateway as a target.

The following procedure is for the Oracle Cloud Infrastructure Console.

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  2. Confirm you're viewing the compartment that contains the cloud network you're interested in.
  3. Click the cloud network you're interested in.
  4. Click Internet Gateways.
  5. Click the Actions icon (three dots) for the internet gateway, and then click Terminate.
  6. Confirm when prompted.

This change disables direct internet connectivity for the VCN.

More information:

Instance has a public IP

Issue: An instance has a public IP address. This means the instance could be publicly addressable if other required components are present and configured correctly in the VCN.

Basics:

  • Carefully consider allowing internet access to any instances. For example, don't accidentally allow internet access to sensitive DB systems.
  • For an instance to be publicly addressable:

    • The instance must have a public IP address and reside in a public subnet in the VCN (instances in private subnets cannot have public IP addresses).
    • The subnet's security list must be configured to allow traffic for all IPs (0.0.0.0/0) and all ports.
    • The VCN must have an internet gateway and be configured to route outbound traffic from the subnet to the internet gateway.
  • An instance can have more than one public IP address. A given public IP is assigned to a private IP on a particular VNIC on the instance. An instance can have more than one VNIC, and each VNIC can have more than one private IP.

To remove a public IP address from an instance:

The following procedure is for the Oracle Cloud Infrastructure Console.

  1. Open the navigation menu. Under Core Infrastructure, go to Compute and click Instances.
  2. Confirm you're viewing the compartment that contains the instance you're interested in.
  3. Click the instance to view its details.
  4. Click Attached VNICs.

    The primary VNIC and any secondary VNICs attached to the instance are displayed.

  5. Click the VNIC you're interested in.

    The VNIC's primary private IP and any secondary private IPs are displayed.

  6. For the private IP you're interested in, click the Actions icon (three dots), and then click Edit.
  7. In the Public IP Address section, for Public IP Type, select the radio button for No Public IP.
  8. Click Update.

The public IP is unassigned from the instance.

More information:

Load balancer has no inbound rules or listeners

Issue: A load balancer's subnet security lists have no ingress rules, or a load balancer has no listener. In this case, the load balancer can't receive incoming traffic.

Basics:

  • Load balancers provide automated traffic distribution from one entry point to multiple servers reachable from your virtual cloud network (VCN). Each load balancer exists in a subnet governed by security list rules. A load balancer receives incoming data traffic from one or more listeners.
  • Security lists provide stateful and stateless firewall capability to control network access to your load balancer and backend servers.
    • If there are no ingress (inbound) rules in any of the subnet's security lists, no traffic is allowed to the instances in that subnet.
    • For defense in depth, configure ingress security list rules to state a specific known source and not an open source (0.0.0.0/0).
  • A listener is a logical entity that checks for incoming traffic on the load balancer's IP address.
    • To handle TCP, HTTP, and HTTPS traffic, you must configure at least one listener per traffic type.
    • You can apply path route rules to a listener to route traffic to the correct backend set without using multiple listeners or load balancers. A path route is a string that the listener matches against an incoming URI to determine the appropriate destination backend set.
  • Ensure that your Oracle Cloud Infrastructure load balancers use inbound rules or listeners to allow access only from known resources.
  • Exceptions can be configured in CASB to reduce alerts from exempted load balancers.
To enable a listener to accept traffic:

The following procedure is for the Oracle Cloud Infrastructure Console.

To enable a listener to accept traffic, you must update your VCN's security list rules:

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.

    The list of VCNs in the current compartment appears.

  2. Click the name of the VCN containing your load balancer, and then click Security Groups or Security Lists.

    A list of the security groups or lists in the cloud network appears.

  3. Click the name of the NSG or security list that applies to your load balancer.

  4. Add or edit the existing rules to allow access from the appropriate resources.

    An NSG's security rules appear on the Network Security Group Details page. From there you can add, edit, or remove rules.

    The Security List Details page provides access to separate tables in which you can add or edit Ingress Rules or Egress Rules.

    For details on rule configuration, see Security Rules.

To create a listener:

Usually, you create a listener as part of the load balancer creation workflow. To create a listener for an existing load balancer:

  1. Open the navigation menu. Under the Core Infrastructure group, go to Networking and click Load Balancers.
  2. Choose the Compartment that contains the load balancer you want to modify, and then click the load balancer's name.
  3. Click Listeners under the Resources menu, then click Create Listener.

    The Create Listener dialog box appears.

  4. Enter the following:

    • Name: Required. Specify a friendly name for the listener. The name must be unique, and cannot be changed. Avoid entering confidential information.
    • Hostname: Optional. Select up to 16 virtual hostnames for this listener.

      Important

      To apply a virtual hostname to a listener, the name must be part of the load balancer's configuration. If the load balancer has no associated hostnames, you can create one on the Hostnames page.
    • Protocol: Required. Specify the protocol to use, either HTTP or TCP.
    • Port: Required. Specify the port on which to listen for incoming traffic.
    • Use SSL: Optional. Check this box to associate an SSL certificate bundle with the listener. The following settings are required to enable SSL handling. See Managing SSL Certificates for more information.

      • Certificate Name: The friendly name of the SSL certificate bundle to use.
      • Verify Peer Certificate: Optional. Select this option to enable peer certificate verification.
      • Verify Depth: Optional. Specify the maximum depth for certificate chain verification.
    • Backend Set: Required. Specify the default backend set to which the listener routes traffic.
    • Idle Timeout in Seconds: Optional. Specify the maximum idle time in seconds. This setting applies to the time allowed between two successive receive or two successive send network input/output operations during the HTTP request-response phase.

      Tip

      The maximum value is 7200 seconds. For more information, see Connection Management.
    • Path Route Set: Optional. Specify the name of the set of path-based routing rules that applies to this listener's traffic.

      Important

      • To apply a path route set to a listener, the set must be part of the load balancer's configuration.
      • To remove a path route set from an existing listener, choose None as the Path Route Set option. The path route set remains available for use by other listeners on this load balancer.
  5. Click Create.

When you create a listener, you must also update your VCN's security list rules to allow traffic to that listener.

More information:

Load balancer has no backend sets

Issue: A load balancer has no backend set. In this case, the load balancer has no place to distribute incoming data and no means to monitor backend server health.

Basics:

  • A backend set is a logical entity defined by a load balancing policy, a health check policy, and a list of backend servers.
  • The backend set determines the load balancer's traffic distribution policy, such as:
    • IP Hash
    • Least Connections
    • Weighted Round Robin
  • You specify the test parameters to confirm the health of backend servers when you create a backend set.
  • If you have an existing load balancer with no backend set, you can specify the backend servers that receive traffic from the load balancer after you create a backend set.
  • You can configure an exception in Oracle CASB Cloud Service to reduce alerts from exempted load balancers.

To create a backend set:

The following procedure is for the Oracle Cloud Infrastructure Console.

Usually, you create a backend set as part of the load balancer creation workflow. To create a backend set for an existing load balancer:

  1. Open the navigation menu. Under the Core Infrastructure group, go to Networking and click Load Balancers.
  2. Click the name of the Compartment that contains the load balancer you want to modify, and then click the load balancer's name.
  3. Click Backend Sets under the Resources menu, then click Create Backend Set.

    The Create Backend Set dialog box appears.

  4. Enter the following:

    • Name: Required. Specify a friendly name for the backend set. It must be unique within the load balancer, and it cannot be changed.

      Valid backend set names include only alphanumeric characters, dashes, and underscores. Backend set names cannot contain spaces. Avoid entering confidential information.

    • Traffic Distribution Policy: Required. Choose the load balancer policy for the backend set. The available options are:

      • IP Hash
      • Least Connections
      • Weighted Round Robin

      For more information on these policies, see How Load Balancing Policies Work.

      Tip

      You cannot add a backend server marked as Backup to a backend set that uses the IP Hash policy.
    • Use SSL: Optional. Check this box to associate an SSL certificate bundle with the backend set.

      If there are no certificate bundles attached to the load balancer, this option is disabled.

      Note

      If you check Use SSL, the SSL Policies fields appear at the bottom of the page.
      • Certificate Name: Required. Select the certificate bundle to use. You can choose any certificate bundle that is attached to the current load balancer. See Managing SSL Certificates for more information.
      • Verify Peer Certificate: Optional. Select this option to enable peer certificate verification.
      • Verify Depth: Optional. Specify the maximum depth for certificate chain verification.
    • Session Persistence: Optional. Specify how the load balancer manages session persistence.

      Important

      See Session Persistence for important information on configuring these settings.
      • Disable Session Persistence: Choose this option to disable cookie-based session persistence.
      • Enable Application Cookie Persistence: Choose this option to enable persistent sessions from a single logical client when the response from a backend application server includes a Set-cookie header with the cookie name you specify.

        • Cookie Name: The cookie name used to enable session persistence. Specify * to match any cookie name. Avoid entering confidential information.
        • Disable Fallback: Check this box to disable fallback when the original server is unavailable.
      • Enable Load Balancer Cookie Persistence: Choose this option to enable persistent sessions based on a cookie inserted by the load balancer.

        • Cookie Name: Specify the name of the cookie used to enable session persistence. If blank, the default cookie name is X-Oracle-BMC-LBS-Route.

          Ensure that any cookie names used at the backend application servers are different from the cookie name used at the load balancer. Avoid entering confidential information.

        • Disable Fallback: Check this box to disable fallback when the original server is unavailable.
        • Domain Name: Optional. Specify the domain in which the cookie is valid.

          This attribute has no default value. If you do not specify a value, the load balancer does not insert the domain attribute into the Set-cookie header.

        • Path: Optional. Specify the path in which the cookie is valid. The default value is /.
        • Expiration Period in Seconds: Optional. Specify the amount of time the cookie remains valid. If blank, the cookie expires at the end of the client session.
        • Attributes

          • Secure: Specify whether the Set-cookie header should contain the Secure attribute. If selected, the client sends the cookie only using a secure protocol.

            If you enable this setting, you cannot associate the corresponding backend set with an HTTP listener.

          • HTTP Only: Specify whether the Set-cookie header should contain the HttpOnly attribute. If selected, the cookie is limited to HTTP requests. The client omits the cookie when providing access to cookies through non-HTTP APIs such as JavaScript channels.
    • Health Check: Required. Specify the test parameters to confirm the health of backend servers.

      • Protocol: Required. Specify the protocol to use, either HTTP or TCP.

        Important

        Configure your health check protocol to match your application or service.
      • Port: Optional. Specify the backend server port against which to run the health check.

        Tip

        You can enter the value '0' to have the health check use the backend server's traffic port.
      • URL Path (URI): (HTTP only) Required. Specify a URL endpoint against which to run the health check.
      • Interval in ms: Optional. Specify how frequently to run the health check, in milliseconds. The default is 10000 (10 seconds).
      • Timeout in ms: Optional. Specify the maximum time in milliseconds to wait for a reply to a health check. A health check is successful only if a reply returns within this timeout period. The default is 3000 (3 seconds).
      • Number of retries: Optional. Specify the number of retries to attempt before a backend server is considered "unhealthy". This number also applies when recovering a server to the "healthy" state. The default is '3'.
      • Status Code: (HTTP only) Optional. Specify the status code a healthy backend server must return.
      • Response Body Regex: (HTTP only) Optional. Provide a regular expression for parsing the response body from the backend server.
  5. Click Create.

After your backend set is provisioned, you must specify backend servers for the set. See Managing Backend Servers for more information.

More information:

Load balancer SSL certificate expires in X days

Issue: A load balancer's SSL certificate expires soon. When the certificate expires, data traffic can be interrupted and security compromised.

Basics:

  • To ensure continuous security and usability, SSL certificates must be rotated on a timely basis.
  • You can configure an exception in Oracle CASB Cloud Service to reduce alerts from exempted load balancers.

To rotate a load balancer's certificate bundle:

The following procedure is for the Oracle Cloud Infrastructure Console.

To ensure consistent service, you must update (rotate) expiring certificates:

  1. Update your client or backend server to work with a new certificate bundle.

    Note

    The steps to update your client or backend server are unique to your system.
  2. Upload the new SSL certificate bundle to the load balancer
    1. Open the navigation menu. Under the Core Infrastructure group, go to Networking and click Load Balancers.
    2. Click the name of the Compartment that contains the load balancer you want to modify, and then click the load balancer's name.
    3. Click the load balancer you want to configure.
    4. In the Resources menu, click Certificates, and then click Add Certificate.
    5. In the Add Certificate dialog box, enter the following:

      • Certificate Name: Required. Specify a friendly name for the certificate bundle. It must be unique within the load balancer, and it cannot be changed in the Console. (It can be changed using the API.) Avoid entering confidential information.
      • Choose SSL Certificate File: Required. Drag and drop the certificate file, in PEM format, into the SSL Certificate field.

        Alternatively, you can choose the Paste SSL Certificate option to paste a certificate directly into this field.

        Important

        If you submit a self-signed certificate for backend SSL, you must submit the same certificate in the corresponding CA Certificate field.
      • Specify CA Certificate: Optional. (Recommended for backend SSL termination configurations.) Select (check) this box if you want to provide a CA certificate.

        • Choose CA Certificate File: Drag and drop the CA certificate file, in PEM format, into the CA Certificate field.

          Alternatively, you can choose the Paste CA Certificate option to paste a certificate directly into this field.

      • Specify Private Key: Optional. (Required for SSL termination.) Select (check) this box if you want to provide a private key for the certificate.

        • Choose Private Key File: Drag and drop the private key, in PEM format, into the Private Key field.

          Alternatively, you can choose the Paste Private Key option to paste a private key directly into this field.

        • Enter Private Key Passphrase: Optional. Specify the private key passphrase.
    6. Click Add Certificate.
  3. Edit listeners or backend sets (as needed) so they use the new certificate bundle

    Editing a listener:

    1. Open the navigation menu. Under the Core Infrastructure group, go to Networking and click Load Balancers.
    2. Choose the Compartment that contains the load balancer you want to modify, and then click the load balancer's name.
    3. In the Resources menu, click Listeners.
    4. For the listener you want to edit, click the Actions icon (three dots), and then click Edit Listener.
    5. In the Certificate Name drop-down list, choose the new certificate bundle.
    6. Click Submit.

    Editing a backend set:

    Warning

    Updating the backend set temporarily interrupts traffic and can drop active connections.
    1. Open the navigation menu. Under the Core Infrastructure group, go to Networking and click Load Balancers.
    2. Click the name of the Compartment that contains the load balancer you want to modify, and then click the load balancer's name.
    3. In the Resources menu, click Backend Sets, and then click the name of the backend set you want to edit.
    4. Click Edit Backend Set.
    5. In the Edit Backend Set dialog box, select (check) Use SSL.
    6. In the Certificate Name drop-down list, choose the new certificate bundle.
    7. Click Save Changes.
  4. (Optional) Remove the expiring SSL certificate bundle
    Important

    You cannot delete an SSL certificate bundle that is associated with a listener or backend set. Remove the bundle from any additional listeners or backend sets before deleting.
    1. Open the navigation menu. Under the Core Infrastructure group, go to Networking and click Load Balancers.
    2. Click the name of the Compartment that contains the load balancer you want to modify, and then click the load balancer's name.
    3. Click the load balancer you want to configure.
    4. In the Resources menu, click Certificates.
    5. For the certificate you want to delete, click the Actions icon (three dots), and then click Delete.
    6. Confirm when prompted.

More information:

Object Storage

Public buckets detected

Issue: Public buckets were detected in your tenancy. Confirm that the creation of each public bucket is intentional and authorized. If the bucket is not sanctioned for public access, follow the procedure for changing the visibility of a bucket and make the bucket private.

Basics:

  • Carefully assess the business requirement for public access to a bucket. When you enable anonymous access to a bucket, users can obtain object metadata, download bucket objects, and optionally list bucket contents.
  • Changing the type of access is bi-directional. You can change a bucket's access from public to private or from private to public.
  • Changing the type of access doesn't affect existing pre-authenticated requests. Existing pre-authenticated requests still work.

To change the visibility of a bucket (private or public):

The following procedure is for the Oracle Cloud Infrastructure Console.

  1. Open the navigation menu. Under Core Infrastructure, click Object Storage.

    A list of the buckets in the compartment you're viewing is displayed. If you don’t see the one you're looking for, verify that you’re viewing the correct compartment (select from the list on the left side of the page).

  2. Click the bucket name to see the bucket details.

    Visibility: shows the current bucket setting, which is Private by default.

  3. Click Edit Visibility.
  4. In the Edit Visibility dialog box, edit the visibility settings:

    • Visibility

      • Public
      • Private
    • If you select Public to enable public access, decide whether or not you want to let users list the bucket contents. Click Allow users to list objects from this bucket to set the visibility of bucket object lists.
  5. Click Save Changes.

More information: