OCI Compute Instances Should Have In-Transit Encryption Enabled

Using Console

To remediate “OCI Compute Instances Should Have In-Transit Encryption Enabled” for OCI Compute Monitoring using the OCI Console, you need to enable in‑transit encryption for the Oracle Cloud Agent Monitoring plugin on each instance.Follow these steps per instance:

Sign in to OCI Console
Make sure you’re in the correct tenancy and region.
Go to the Compute instance
- Open the navigation menu (☰).
- Go to Compute → Instances.
- Select the Compartment where the instance is.
- Click the instance name you want to fix.
Open Oracle Cloud Agent plugins
- On the instance details page, in the left-side or main tabs, click Oracle Cloud Agent (or Oracle Cloud Agent plugins).
- You’ll see a list of plugins like:
  - Monitoring
  - Management Agent
  - Block Volume Management
  - etc.
Edit the Monitoring plugin configuration
- Find the Monitoring plugin in the list.
- Ensure its Status is Enabled (if not, click Edit or the action menu (⋯) → Enable).
- In the same area, look for In‑transit encryption or similar security/encryption option.
- Click Edit (or the pencil icon) for the Monitoring plugin configuration.
Enable in‑transit encryption
- In the plugin settings, set In‑transit encryption (or Encrypt data in transit / Use TLS for monitoring data) to Enabled.
- If prompted, choose the appropriate protocol (TLS) and minimum version (e.g., TLS 1.2 or higher).
- Save the changes by clicking Save or Update.
Verify plugin and encryption status
- After saving, confirm:
  - Monitoring plugin is Enabled.
  - In‑transit encryption shows as Enabled for that plugin.
- Optionally, check a few other instances in the same compartment and repeat.
Repeat for all affected instances
- Apply the same configuration for each instance flagged by your security/compliance tool or Cloud Guard.

If your organization uses instance configuration / instance pools, update the instance configuration with these agent settings and then recreate or refresh instances from that configuration so new instances inherit in‑transit encryption by default.

Using CLI

Below is how to remediate the “OCI Compute Instances Should Have In-Transit Encryption Enabled” finding using the OCI CLI, focusing on block/boot volume attachments to compute instances.In-transit encryption is a property of the volume attachment, not the instance or volume itself, so you must (re)attach with encryption-in-transit enabled.

1. Prerequisites

OCI CLI installed and configured:
oci setup config
You know:
- Your tenancy OCID
- The compartment OCID(s) where the instances reside
- Proper permissions (read and manage on compute and block volumes).

2. Identify Non-Compliant Volume Attachments

List all volume attachments in a compartment and filter for those without in-transit encryption.

COMPARTMENT_OCID="<your_compartment_ocid>"

oci compute volume-attachment list \
  --compartment-id "$COMPARTMENT_OCID" \
  --all \
  --output table

Check for these fields on each attachment:

isPvEncryptionInTransitEnabled (for paravirtualized attachments)
isIscsiEncryptionEnabled (for iSCSI, if present)

You want all of these to be True.To programmatically find non-compliant ones (example using jq):

oci compute volume-attachment list \
  --compartment-id "$COMPARTMENT_OCID" \
  --all \
  --raw-output \
| jq -r '.data[]
  | select(
      (.["is-pv-encryption-in-transit-enabled"] == false)
      or (.["is-iscsi-encryption-enabled"] == false)
    )
  | {id, instanceId, volumeId, attachmentType,
     isPvEncryptionInTransitEnabled: ."is-pv-encryption-in-transit-enabled",
     isIscsiEncryptionEnabled: ."is-iscsi-encryption-enabled"}'

Record for each non-compliant attachment:

id (volume attachment OCID)
instanceId
volumeId
attachmentType (paravirtualized / iscsi)

3. Stop the Affected Instance (Required for Detach)

For each affected instanceId:

INSTANCE_OCID="<instance_ocid>"

oci compute instance action \
  --instance-id "$INSTANCE_OCID" \
  --action STOP

Wait until the instance is STOPPED:

oci compute instance get \
  --instance-id "$INSTANCE_OCID" \
  --query 'data."lifecycle-state"' \
  --raw-output

4. Detach the Existing (Non-Encrypted-in-Transit) Volume Attachment

For each non-compliant volumeAttachmentId:

VOLUME_ATTACHMENT_OCID="<volume_attachment_ocid>"

oci compute volume-attachment detach \
  --volume-attachment-id "$VOLUME_ATTACHMENT_OCID"

Wait for the attachment to be removed (optional check):

oci compute volume-attachment get \
  --volume-attachment-id "$VOLUME_ATTACHMENT_OCID"
# Will fail or show TERMINATED when fully detached

5. Reattach the Volume with In-Transit Encryption Enabled

You need:

instanceId (same as before)
volumeId
attachmentType (paravirtualized or iscsi)
For boot volumes: use the boot volume attachment commands.
For data volumes: use the volume attachment commands.

5.1. Reattach a Data Volume (Paravirtualized)

INSTANCE_OCID="<instance_ocid>"
VOLUME_OCID="<volume_ocid>"
AVAILABILITY_DOMAIN="<AD_from_original_attachment>"  # e.g. "kIdk:US-ASHBURN-AD-1"

oci compute volume-attachment attach \
  --instance-id "$INSTANCE_OCID" \
  --volume-id "$VOLUME_OCID" \
  --type paravirtualized \
  --availability-domain "$AVAILABILITY_DOMAIN" \
  --is-pv-encryption-in-transit-enabled true

5.2. Reattach a Data Volume (iSCSI)

INSTANCE_OCID="<instance_ocid>"
VOLUME_OCID="<volume_ocid>"
AVAILABILITY_DOMAIN="<AD_from_original_attachment>"

oci compute volume-attachment attach \
  --instance-id "$INSTANCE_OCID" \
  --volume-id "$VOLUME_OCID" \
  --type iscsi \
  --availability-domain "$AVAILABILITY_DOMAIN" \
  --is-iscsi-encryption-enabled true

5.3. Reattach a Boot Volume with In-Transit Encryption

For boot volumes, use attach-boot-volume:

BOOT_VOLUME_OCID="<boot_volume_ocid>"
INSTANCE_OCID="<instance_ocid>"
AVAILABILITY_DOMAIN="<AD_from_original_attachment>"

oci compute boot-volume-attachment attach \
  --instance-id "$INSTANCE_OCID" \
  --boot-volume-id "$BOOT_VOLUME_OCID" \
  --availability-domain "$AVAILABILITY_DOMAIN" \
  --is-pv-encryption-in-transit-enabled true

(Use the same attachment type and AD as originally.)

6. Restart the Instance

INSTANCE_OCID="<instance_ocid>"

oci compute instance action \
  --instance-id "$INSTANCE_OCID" \
  --action START

7. Validate In-Transit Encryption Is Enabled

Re-list the volume attachments:

oci compute volume-attachment list \
  --compartment-id "$COMPARTMENT_OCID" \
  --all \
  --raw-output \
| jq -r '.data[]
  | {id, instanceId, volumeId,
     isPvEncryptionInTransitEnabled: ."is-pv-encryption-in-transit-enabled",
     isIscsiEncryptionEnabled: ."is-iscsi-encryption-enabled"}'

Confirm that:

is-pv-encryption-in-transit-enabled is true for paravirtualized
is-iscsi-encryption-enabled is true for iSCSI

If you share an example attachment JSON from your environment, I can give exact CLI commands tailored to that specific instance and volume.

Using Python

In OCI there is no toggle on a Compute instance called “in‑transit encryption.” It’s enforced by how you expose and connect to the instance (HTTPS, SSH, VPN, SSL/TLS on load balancer, etc.).For “OCI Compute Instances Should Have In-Transit Encryption Enabled” as a monitoring control, what you can do in Python is:

Continuously discover public‑facing compute endpoints.
Check whether they are using TLS (HTTPS/SSL) or plaintext (HTTP/other).
Optionally auto‑remediate (e.g., tag non‑compliant instances or send an alarm / notification for manual HTTPS enforcement via LB / web server config).

Below is a minimal, practical approach to add such monitoring with Python and OCI SDK.

1. Prerequisites

Python 3.x
oci SDK installed:
pip install oci
OCI config file (~/.oci/config) with a profile that has:
- Compute:Read
- VirtualNetwork:Read
- Monitoring:manage (if you want to create alarms)
- Ons:manage or Events/Notifications if you’ll send notifications

2. Discover Compute instances and their public endpoints

This script:

Lists all instances in a compartment
Finds their VNICs & public IPs
Records TCP ports that look like HTTP/HTTPS (80, 443, others if you choose)

import oci

config = oci.config.from_file("~/.oci/config", "DEFAULT")
compute_client = oci.core.ComputeClient(config)
vn_client = oci.core.VirtualNetworkClient(config)

COMPARTMENT_ID = "<your_compartment_ocid>"

def list_instances(compartment_id):
    instances = oci.pagination.list_call_get_all_results(
        compute_client.list_instances,
        compartment_id=compartment_id,
        lifecycle_state="RUNNING"
    ).data
    return instances

def get_instance_public_ips(instance):
    vnic_attachments = oci.pagination.list_call_get_all_results(
        compute_client.list_vnic_attachments,
        compartment_id=instance.compartment_id,
        instance_id=instance.id
    ).data

    public_ips = []
    for va in vnic_attachments:
        vnic = vn_client.get_vnic(va.vnic_id).data
        if vnic.public_ip:
            public_ips.append(vnic.public_ip)
    return public_ips

instances = list_instances(COMPARTMENT_ID)
instance_endpoints = []  # (instance_id, name, ip)
for inst in instances:
    ips = get_instance_public_ips(inst)
    for ip in ips:
        instance_endpoints.append((inst.id, inst.display_name, ip))

print("Public endpoints:")
for eid, name, ip in instance_endpoints:
    print(name, ip)

At this point you know which instances are internet‑facing.

3. Check in‑transit encryption status (simple TCP/TLS check)

For monitoring, a pragmatic test is:

Try connecting via HTTPS (443) and validate the TLS handshake.
Optionally, detect if HTTP (80) is open and serving plaintext.

import socket
import ssl

def check_tls(ip, port=443, timeout=3):
    ctx = ssl.create_default_context()
    conn = ctx.wrap_socket(socket.socket(socket.AF_INET), server_hostname=ip)
    conn.settimeout(timeout)
    try:
        conn.connect((ip, port))
        cert = conn.getpeercert()
        conn.close()
        return True, cert
    except Exception as e:
        return False, str(e)

def check_plain_http(ip, port=80, timeout=3):
    s = socket.socket()
    s.settimeout(timeout)
    try:
        s.connect((ip, port))
        s.sendall(b"GET / HTTP/1.1\r\nHost: %b\r\n\r\n" % ip.encode())
        data = s.recv(1024)
        s.close()
        # if we got any response, HTTP is likely enabled
        return True, data[:80]
    except Exception as e:
        return False, str(e)

non_compliant = []

for inst_id, name, ip in instance_endpoints:
    tls_ok, tls_info = check_tls(ip, 443)
    http_open, http_info = check_plain_http(ip, 80)

    if not tls_ok and http_open:
        non_compliant.append({
            "instance_id": inst_id,
            "name": name,
            "ip": ip,
            "issue": "HTTP open without working HTTPS"
        })

print("Non‑compliant instances:")
for item in non_compliant:
    print(item)

This gives you a monitoring view: which compute instances are serving unencrypted HTTP but not working HTTPS.

4. Publish results as custom metrics to OCI Monitoring

Create a custom metric namespace (e.g. security/compute_encryption) and push a metric like unencrypted_endpoints per instance.

from datetime import datetime, timezone

monitoring_client = oci.monitoring.MonitoringClient(config)
NAMESPACE = "security/compute_encryption"
METRIC_NAME = "unencrypted_endpoints"

def push_metric(instance_id, value):
    now = datetime.now(timezone.utc).isoformat()
    metric_data = oci.monitoring.models.MetricDataDetails(
        namespace=NAMESPACE,
        compartment_id=COMPARTMENT_ID,
        name=METRIC_NAME,
        dimensions={"instanceId": instance_id},
        datapoints=[
            oci.monitoring.models.Datapoint(
                timestamp=now,
                value=value
            )
        ],
        resource_group="default"
    )

    post = oci.monitoring.models.PostMetricDataDetails(
        metric_data=[metric_data]
    )

    monitoring_client.post_metric_data(post)

# For every instance, 0 = compliant, 1 = non‑compliant
non_compliant_ids = {n["instance_id"] for n in non_compliant}

for inst_id, name, ip in instance_endpoints:
    value = 1 if inst_id in non_compliant_ids else 0
    push_metric(inst_id, value)

Now you have a Monitoring metric indicating in‑transit encryption compliance per instance.

5. Create an OCI Monitoring Alarm (in console) on this metric

In OCI Console → Monitoring → Alarms:

Create alarm
- Metric namespace: security/compute_encryption
- Metric name: unencrypted_endpoints
- Dimension: instanceId (All)
- Query example:
  security/compute_encryption.unencrypted_endpoints[1m].max() > 0
Severity: Critical / High
Destination: Choose/Configure Notifications (Email, PagerDuty, etc.)

This turns your Python script into an in‑transit encryption monitor.

6. Operational remediation (what actually fixes the misconfiguration)

The script only detects and monitors. To remediate per instance (done outside Python or via automation):

For web workloads:
- Put instance behind an OCI Load Balancer with an HTTPS listener and valid certificate.
- Or configure the web server (Nginx/Apache/etc.) on the instance to:
  - Enable HTTPS
  - Redirect all HTTP → HTTPS
For APIs/other services:
- Require TLS (e.g., gRPC over TLS, TLS for custom TCP protocols).
For admin access:
- Use SSH (already encrypted) instead of telnet/rsh, etc.
- Use VPN / FastConnect for private access only.

You can extend the Python script to:

Tag non‑compliant instances: encryption_in_transit = "non_compliant"
Or send an Operations ticket / webhook for manual remediation.

If you specify your exact protocol/port (e.g., HTTP on 8080, custom API on 8443), I can adjust the example checks and metrics code accordingly.

Using Terraform

# Enable in-transit encryption for the boot volume attachment of an OCI compute instance
resource "oci_core_boot_volume_attachment" "this" {
  # Replace with your own values
  availability_domain = "AVAILABILITY_DOMAIN_NAME"
  compartment_id      = "COMPARTMENT_OCID"
  instance_id         = "INSTANCE_OCID"
  boot_volume_id      = "BOOT_VOLUME_OCID"

  # This is the setting the finding is about
  is_pv_encryption_in_transit_enabled = true
}

# Enable in-transit encryption for a block volume attachment on the same instance
resource "oci_core_volume_attachment" "this" {
  # Replace with your own values
  attachment_type     = "paravirtualized" # or "iscsi", as appropriate
  availability_domain = "AVAILABILITY_DOMAIN_NAME"
  compartment_id      = "COMPARTMENT_OCID"
  instance_id         = "INSTANCE_OCID"
  volume_id           = "BLOCK_VOLUME_OCID"

  # This is the setting the finding is about
  is_pv_encryption_in_transit_enabled = true
}

In-transit encryption is configured on boot and block volume attachments, not on the oci_core_instance or monitoring resources, so it cannot be remediated via “OCI Compute Monitoring” directly.Changing is_pv_encryption_in_transit_enabled from false to true may force replacement of the volume attachment (detach/attach), which can cause downtime for that volume.Verification: terraform plan should show is_pv_encryption_in_transit_enabled: "false" => "true" on the relevant oci_core_boot_volume_attachment and/or oci_core_volume_attachment resources.

OCI Misconfigurations

OCI Compute Instances Should Have In-Transit Encryption Enabled

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

1. Prerequisites

2. Identify Non-Compliant Volume Attachments

3. Stop the Affected Instance (Required for Detach)

4. Detach the Existing (Non-Encrypted-in-Transit) Volume Attachment

5. Reattach the Volume with In-Transit Encryption Enabled

5.1. Reattach a Data Volume (Paravirtualized)

5.2. Reattach a Data Volume (iSCSI)

5.3. Reattach a Boot Volume with In-Transit Encryption

6. Restart the Instance

7. Validate In-Transit Encryption Is Enabled

1. Prerequisites

2. Discover Compute instances and their public endpoints

3. Check in‑transit encryption status (simple TCP/TLS check)

4. Publish results as custom metrics to OCI Monitoring

5. Create an OCI Monitoring Alarm (in console) on this metric

6. Operational remediation (what actually fixes the misconfiguration)

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation

​1. Prerequisites

​2. Identify Non-Compliant Volume Attachments

​3. Stop the Affected Instance (Required for Detach)

​4. Detach the Existing (Non-Encrypted-in-Transit) Volume Attachment

​5. Reattach the Volume with In-Transit Encryption Enabled

​5.1. Reattach a Data Volume (Paravirtualized)

​5.2. Reattach a Data Volume (iSCSI)

​5.3. Reattach a Boot Volume with In-Transit Encryption

​6. Restart the Instance

​7. Validate In-Transit Encryption Is Enabled

​1. Prerequisites

​2. Discover Compute instances and their public endpoints

​3. Check in‑transit encryption status (simple TCP/TLS check)

​4. Publish results as custom metrics to OCI Monitoring

​5. Create an OCI Monitoring Alarm (in console) on this metric

​6. Operational remediation (what actually fixes the misconfiguration)

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

1. Prerequisites

2. Identify Non-Compliant Volume Attachments

3. Stop the Affected Instance (Required for Detach)

4. Detach the Existing (Non-Encrypted-in-Transit) Volume Attachment

5. Reattach the Volume with In-Transit Encryption Enabled

5.1. Reattach a Data Volume (Paravirtualized)

5.2. Reattach a Data Volume (iSCSI)

5.3. Reattach a Boot Volume with In-Transit Encryption

6. Restart the Instance

7. Validate In-Transit Encryption Is Enabled

1. Prerequisites

2. Discover Compute instances and their public endpoints

3. Check in‑transit encryption status (simple TCP/TLS check)

4. Publish results as custom metrics to OCI Monitoring

5. Create an OCI Monitoring Alarm (in console) on this metric

6. Operational remediation (what actually fixes the misconfiguration)