Info icon
End of Life Notice: For Trend Cloud One™ - Conformity Customers, Conformity will reach its End of Sale on “July 31st, 2025” and End of Life “July 31st, 2026”. The same capabilities and much more is available in TrendAI Vision One™ Cloud Risk Management. For details, please refer to Upgrade to TrendAI Vision One™
Logo of TrendAI
Use the Knowledge Base AI to help improve your Cloud Posture

Check for Private Subnet Deployment for Function Applications

TrendAI Vision One™ provides continuous assurance that gives peace of mind for your cloud infrastructure, delivering over 1400 automated best practice checks.

Risk Level: Medium (should be achieved)
Rule ID: OCI-Functions-003

Ensure that your Oracle Cloud Infrastructure (OCI) Functions applications are deployed in private subnets instead of public subnets, to minimize the attack surface and limit direct exposure to the public internet. While deploying functions in private subnets does not prevent access to the function invoke endpoints (which requires IAM policies for access control), it is a foundational network security control that supports private communication with other OCI resources such as databases, storage, and compute instances within your Virtual Cloud Network (VCN). Private subnets require a service gateway in the VCN to enable functions to access Oracle services (such as Oracle Cloud Infrastructure Registry) without internet exposure.

Security

Deploying Oracle Cloud Infrastructure (OCI) Functions applications in private subnets provides several security benefits by reducing the attack surface and enforcing network segmentation. Private subnet deployment ensures that functions communicate with other cloud resources over Oracle's private network fabric rather than traversing the public internet, which reduces the risk of data interception and unauthorized access. When combined with service gateways, functions in private subnets can securely access Oracle services such as Object Storage and Container Registry without requiring internet gateways or NAT gateways, maintaining a fully private network architecture. This approach aligns with defense-in-depth security practices and helps organizations meet compliance requirements that mandate restricted network access for sensitive workloads.

Note that deploying a Functions application in a private subnet does not automatically prevent internet-based access to the function invoke endpoints. Access control to invoke endpoints must be implemented through IAM policies that restrict which users and services can invoke functions.

Audit

To determine if your OCI Functions applications are deployed in private subnets, perform the following operations:

Using OCI Console

  1. Sign in to your Oracle Cloud Infrastructure (OCI) account.

  2. Navigate to Functions console available at https://cloud.oracle.com/functions/.

  3. Choose the OCI compartment that you want to access from the Compartment dropdown list.

  4. In the Applications list, click on the name (link) of the Functions application that you want to examine.

  5. Select the Details tab and check the Subnets attribute value, listed under Network configuration.

  6. Click on the subnet name (link) to view the subnet details.

  7. On the subnet details page, check the Subnet access attribute value under Subnet information. If Subnet access is set to Public Subnet, the selected subnet is a public subnet, which means the Oracle Cloud Infrastructure (OCI) Functions application is not deployed in a private subnet and is therefore exposed to higher network security risks.

  8. Repeat steps no. 4 – 7 for each Functions application available in the selected compartment.

  9. Repeat steps no. 3 – 8 for each compartment available within your Oracle Cloud Infrastructure (OCI) account.

Using OCI CLI

  1. Run iam compartment list command (Windows/macOS/Linux) with output query filters to list the ID of each compartment available in your Oracle Cloud Infrastructure (OCI) account:

    oci iam compartment list
	--all
	--include-root
	--query 'data[]."id"'

  2. The command output should return the requested OCI compartment identifiers (OCIDs):

    [
	"ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
	"ocid1.compartment.oc1..abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd"
]

  3. Run fn application list command (Windows/macOS/Linux) with the ID of the OCI compartment that you want to examine as the identifier parameter, to list the ID of each Functions application available in the selected OCI compartment:

    oci fn application list
	--compartment-id 'ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--all
	--query 'data[]."id"'

  4. The command output should return the requested Functions application IDs:

    [
	"ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
	"ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcdabcd1234abcd1234abcd1234abcd1234abcd1234"
]

  5. Run fn application get command (Windows/macOS/Linux) with the ID of the Functions application that you want to examine as the identifier parameter and custom output filters to list the subnet IDs associated with the selected application:

    oci fn application get
	--application-id 'ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--query 'data."subnet-ids"'

  6. The command output should return the subnet OCID(s) for the specified Functions application:

    [
	"ocid1.subnet.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd"
]

  7. Run network subnet get command (Windows/macOS/Linux) with the ID of the subnet returned in the previous step as the identifier parameter, to describe the configuration of the selected subnet:

    oci network subnet get
	--subnet-id 'ocid1.subnet.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--query 'data'

  8. The command output should return the configuration metadata for the selected subnet:

    {
	"availability-domain": null,
	"cidr-block": "10.0.1.0/24",
	"compartment-id": "ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
	"defined-tags": {},
	"dhcp-options-id": "ocid1.dhcpoptions.oc1.ap-sydney-1.aaaabbbbccccdddd",
	"display-name": "cc-public-subnet",
	"dns-label": "publicsubnet",
	"freeform-tags": {},
	"id": "ocid1.subnet.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
	"ipv6-cidr-block": null,
	"ipv6-cidr-blocks": null,
	"ipv6-virtual-router-ip": null,
	"lifecycle-state": "AVAILABLE",
	"prohibit-internet-ingress": false,
	"prohibit-public-ip-on-vnic": false,
	"route-table-id": "ocid1.routetable.oc1.ap-sydney-1.aaaabbbbccccdddd",
	"security-list-ids": [
		"ocid1.securitylist.oc1.ap-sydney-1.aaaabbbbccccdddd"
	],
	"subnet-domain-name": "publicsubnet.ccvcn.oraclevcn.com",
	"time-created": "2025-01-15T10:30:00.123000+00:00",
	"vcn-id": "ocid1.vcn.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234",
	"virtual-router-ip": "10.0.1.1",
	"virtual-router-mac": "00:00:17:12:AB:CD"
}

    Check the "prohibit-public-ip-on-vnic" property value returned by the network subnet get command output. If the "prohibit-public-ip-on-vnic" value is set to false, as shown in the example above, the selected subnet is a public subnet, which means the Oracle Cloud Infrastructure (OCI) Functions application is not deployed in a private subnet and is therefore exposed to higher network security risks.

  9. Repeat steps no. 5 – 8 to verify the subnet configuration for other Functions applications available in the selected compartment.

  10. Repeat steps no. 3 – 9 for each compartment available within your Oracle Cloud Infrastructure (OCI) account.

Remediation / Resolution

To migrate your existing Oracle Cloud Infrastructure (OCI) Functions applications to private subnets, you must update the subnet configuration for each application by performing the following operations:

Important considerations before migrating to private subnets:
  • Ensure that a service gateway exists in your VCN and is properly configured to allow access to Oracle Services Network. The service gateway enables functions in private subnets to access services such as Oracle Cloud Infrastructure Registry and Object Storage without requiring internet access.
  • Verify that your VCN route tables include a route rule that directs traffic destined for Oracle services to the service gateway.
  • Update security lists to allow egress traffic to Oracle Services Network (use the service CIDR label for your region).
  • If your functions need to access resources on the internet (such as third-party APIs), you will need to configure a NAT gateway in the VCN and update route tables accordingly.
  • Changing the subnet configuration may cause a brief interruption in function execution during the update.

Using OCI Console

  1. Sign in to your Oracle Cloud Infrastructure (OCI) account.

  2. Navigate to Networking console available at https://cloud.oracle.com/networking/.

  3. Choose the OCI compartment that contains your VCN from the Compartment dropdown list.

  4. In the left navigation panel, under Virtual cloud networks, choose Virtual cloud networks to list the VCNs in the selected compartment.

  5. Click on the name (link) of the VCN that hosts your Functions application subnets.

  6. In the left navigation panel, under Resources, choose Service gateways to verify that a service gateway exists. If no service gateway exists, choose Create service gateway and perform the following actions:

    1. For Name, provide a unique name for the service gateway (e.g., "cc-service-gateway").
    2. For Create in compartment, ensure the appropriate compartment is selected.
    3. For Services, choose All Services in Oracle Services Network to enable access to all Oracle services.
    4. Choose Create service gateway to create the gateway.

  7. In the left navigation panel, under Resources, choose Route tables and verify that the route table associated with your private subnet includes a route rule for the service gateway. If not, click on the route table name and perform the following actions:

    1. Choose Add route rules under the Route rules section.
    2. For Target type, select Service gateway.
    3. For Destination service, choose All Services in Oracle Services Network.
    4. For Target service gateway, select the service gateway created in step 6.
    5. Choose Add route rules to save the route rule.

  8. Navigate to Functions console available at https://cloud.oracle.com/functions/.

  9. Choose the OCI compartment that you want to access from the Compartment dropdown list.

  10. In the Applications list, click on the name (link) of the Functions application that you want to reconfigure (see Audit section part I to identify the right resource).

  11. Choose Edit from the top menu to modify the application configuration.

  12. In the Edit application dialog box, perform the following actions:

    1. For VCN in , ensure the correct VCN is selected (the same VCN where you configured the service gateway).
    2. For Subnets in , deselect any public subnets and choose one or more private subnets (subnets where "prohibit-public-ip-on-vnic" is set to true). You can select up to three private subnets for high availability.
    3. Choose Save changes to apply the new subnet configuration.

  13. Wait for the application update to complete. The application status should return to Active.

  14. Repeat steps no. 10 – 13 for other Functions applications that are deployed in public subnets.

  15. Repeat steps no. 9 – 14 for each compartment available within your Oracle Cloud Infrastructure (OCI) account.

Using OCI CLI

  1. Run fn application get command (Windows/macOS/Linux) with the ID of the Functions application that you want to reconfigure (see Audit section part II to identify the right resource) as the identifier parameter, to retrieve the current application configuration:

    oci fn application get
	--application-id 'ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--query 'data'

  2. The command output should return the current configuration of the specified application. Note the VCN ID and current subnet IDs for reference.

  3. Run network subnet list command (Windows/macOS/Linux) to identify the private subnet OCID(s) in the VCN where you want to deploy the application:

    oci network subnet list
	--compartment-id 'ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--vcn-id 'ocid1.vcn.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--all
	--query "data[?\"prohibit-public-ip-on-vnic\"==\`true\`].{name:\"display-name\", id:id}"

  4. The command output should return the names and IDs of private subnets in the VCN:

    [
	{
		"id": "ocid1.subnet.oc1.ap-sydney-1.aaaabbbbccccddddabcdabcd1234abcd1234abcd1234abcd1234abcd1234",
		"name": "cc-private-subnet"
	}
]

  5. Run fn application update command (Windows/macOS/Linux) with the ID of the Functions application that you want to reconfigure as the identifier parameter, to update the application to use private subnets. Replace the subnet IDs with the private subnet OCID(s) identified in step 4:

    oci fn application update
	--application-id 'ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--subnet-ids '["ocid1.subnet.oc1.ap-sydney-1.aaaabbbbccccddddabcdabcd1234abcd1234abcd1234abcd1234abcd1234"]'

  6. The command output should return the updated configuration information for the Functions application:

    {
	"compartment-id": "ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
	"config": {},
	"defined-tags": {},
	"display-name": "cc-function-app",
	"freeform-tags": {},
	"id": "ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
	"image-policy-config": {
	"is-policy-enabled": false,
	"key-details": null
	},
	"lifecycle-state": "ACTIVE",
	"network-security-group-ids": [],
	"shape": "GENERIC_X86",
	"subnet-ids": [
	"ocid1.subnet.oc1.ap-sydney-1.aaaabbbbccccddddabcdabcd1234abcd1234abcd1234abcd1234abcd1234"
	],
	"syslog-url": null,
	"time-created": "2025-01-15T10:45:00.456000+00:00",
	"time-updated": "2025-02-16T14:20:00.789000+00:00",
	"trace-config": null
}

  7. Repeat steps no. 1 – 6 for other Functions applications that are deployed in public subnets.

References

Publication date Feb 24, 2026

Related OCI-Functions rules