Skip to main content

OCI Compute Instances Should Have In-Transit Encryption

More Info:​

Compute instances should have in-transit encryption enabled for boot and block volume attachments. This protects data from interception as it moves between the instance and storage

Risk Level​

Medium

Address​

Compliance, Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • AWS Startup Security Baseline
  • AWS Well Architected Framework
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • GDPR
  • HIPAA
  • ISO 27001
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST CSF
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • PCI
  • Reserve Bank of India (RBI) Cyber Security Framework
  • SOC2
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
  • UK NCSC Cyber Assessment Framework

Triage and Remediation​

Remediation​

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:

  1. Sign in to OCI Console
    Make sure you’re in the correct tenancy and region.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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:

  1. Continuously discover public‑facing compute endpoints.
  2. Check whether they are using TLS (HTTPS/SSL) or plaintext (HTTP/other).
  3. 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:

  1. Create alarm
    • Metric namespace: security/compute_encryption
    • Metric name: unencrypted_endpoints
    • Dimension: instanceId (All)
    • Query example: 
      security/compute_encryption.unencrypted_endpoints[1m].max() > 0
  2. Severity: Critical / High
  3. 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.