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 Resource-Level Access Controls in Function IAM Policies

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-005

Ensure that your Oracle Cloud Infrastructure (OCI) IAM policies implement resource-level access controls for Functions by using specific application or function OCIDs in policy conditions rather than granting blanket access to all functions in a compartment. Resource-level access controls use policy condition clauses such as where target.app.id = '<application-OCID>' to restrict access to specific applications, or where target.function.id = '<function-OCID>' to restrict access to individual functions. Without these conditions, a policy statement like Allow group FunctionsInvokers to use fn-invocation in compartment cc-functions-compartment grants permission to invoke all functions in the entire compartment, which may include sensitive functions that should have restricted access.

Security

Implementing resource-level access controls for Oracle Cloud Infrastructure (OCI) Functions significantly enhances security by enforcing the principle of least privilege at the individual resource level rather than just at the compartment level. When IAM policies grant function access at the compartment level without resource-specific conditions, users receive permission to invoke or manage all functions within that compartment, regardless of whether they actually need access to all of them. This creates several security risks including unauthorized access to sensitive functions (users invoking functions that process confidential data or perform privileged operations), accidental invocation of critical functions (users mistakenly triggering production functions instead of development functions), cross-team access violations (members of one team accessing another team's functions when both teams share a compartment), and increased blast radius of compromised credentials (stolen credentials can be used to invoke or modify any function in the compartment). By using resource-level conditions with specific function or application OCIDs, organizations can create precise access boundaries that align with actual business requirements and job responsibilities.

Audit

To determine if your OCI IAM policies implement resource-level access controls for Functions, perform the following operations:

Using OCI Console

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

  2. Navigate to Identity & Security console available at https://cloud.oracle.com/identity/.

  3. In the left navigation panel, under Identity, choose Policies to list the IAM policies.

  4. Choose the OCI compartment that you want to examine from the Compartment dropdown list on the left side. Review policies in all compartments, including the root compartment.

  5. Click on the name (link) of the IAM policy that contains Functions-related permissions.

  6. Select the Policy statements section and review each policy statement that grants Functions access. Look for the following security issues:

    • Policy statements granting use fn-invocation without resource-level conditions (missing where target.app.id = '' or where target.function.id = ''), allowing users to invoke all functions in the compartment regardless of whether they need access to all of them.
    • Policy statements granting manage fn-function or manage fn-app without resource-level conditions, allowing users to manage all functions or applications in the compartment when they should only manage specific ones.
    • Policy statements that grant access at the compartment level when more granular application-level or function-level access would be more appropriate based on the user group's responsibilities.

  7. For each policy statement lacking resource-level conditions, determine whether all users in the group genuinely need access to all functions in the compartment, or whether access should be restricted to specific applications or functions.

  8. If you identify policy statements that grant Functions access (use fn-invocation, manage fn-function, or manage fn-app) at the compartment level without resource-level conditions when more granular access would be appropriate, the selected Oracle Cloud Infrastructure (OCI) IAM policy does not implement proper resource-level access controls, creating unnecessary security exposure by granting broader access than required.

  9. Repeat steps no. 5 – 8 for each IAM policy available in the selected compartment.

  10. Repeat steps no. 4 – 9 for each compartment, including the root compartment (tenancy), 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 iam policy list command (Windows/macOS/Linux) with the ID of the OCI compartment that you want to examine as the identifier parameter, to list IAM policies:

    oci iam policy list
	--compartment-id 'ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--all
	--lifecycle-state 'ACTIVE'
	--query 'data[].{id:id, name:name}'

  4. The command output should return policy identifiers and names:

    [
	{
		"id": "ocid1.policy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
		"name": "cc-functions-access-policy"
	},
	{
		"id": "ocid1.policy.oc1..aaaabbbbccccddddabcdabcd1234abcd1234abcd1234abcd1234abcd1234",
		"name": "cc-functions-dev-policy"
	}
]

  5. Run iam policy get command (Windows/macOS/Linux) with the ID of each IAM policy to examine the policy statements:

    oci iam policy get
	--policy-id 'ocid1.policy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--query 'data.statements'

  6. The command output should return the policy statements:

    [
	"Allow group FunctionsInvokers to use fn-invocation in compartment cc-functions-compartment",
	"Allow group FunctionsDevelopers to manage fn-function in compartment cc-functions-compartment"
]
    Review each policy statement and look for the following security issues:
    • Policy statements granting "use fn-invocation" without resource-level conditions (missing "where target.app.id = ''" or "where target.function.id = ''"), allowing users to invoke all functions in the compartment.
    • Policy statements granting "manage fn-function" or "manage fn-app" without resource-level conditions, allowing users to manage all functions or applications when they should only manage specific ones.
    • Lack of where clauses with target.app.id or target.function.id conditions when granular access control would be more appropriate.

    In the example output above, both policy statements grant access at the compartment level without any resource-level conditions, allowing users to invoke or manage all functions in the compartment. If users should only have access to specific applications or functions, the selected Oracle Cloud Infrastructure (OCI) IAM policy does not implement proper resource-level access controls.

  7. Repeat steps no. 5 and 6 to verify policy statements for other IAM policies available in the selected compartment.

  8. Repeat steps no. 3 – 7 for each compartment, including the root compartment (tenancy), available within your Oracle Cloud Infrastructure (OCI) account.

Remediation / Resolution

To implement resource-level access controls in your Oracle Cloud Infrastructure (OCI) Functions IAM policies, perform the following operations:

Important considerations before implementing resource-level access controls:
  • Identify required function access: Before modifying policies, document which user groups need access to which specific functions or applications. Gather the OCIDs of the applications and functions that each group should access.
  • Obtain resource OCIDs: You will need the OCIDs of Functions applications and individual functions to use in policy conditions. Use the fn application list and fn function list CLI commands or the Functions console to retrieve these OCIDs.
  • Consider application-level vs. function-level restrictions: In most cases, restricting access at the application level using target.app.id is sufficient and easier to manage than function-level restrictions. Use function-level restrictions (target.function.id) only when users need access to specific functions within an application rather than the entire application.
  • Plan for multiple resources: If a user group needs access to multiple applications or functions, use the ANY operator in policy conditions to specify multiple OCIDs in a single statement.
  • Test policy changes: Resource-level conditions immediately restrict access. Test new policies in a non-production environment first to ensure users can access the functions they need.
  • Document OCID mappings: Maintain documentation mapping user groups to the specific application/function OCIDs they can access, as OCIDs are not human-readable.
  • Consider policy maintenance: Resource-level policies require updates when new functions or applications are created. Plan a process for updating policies as your Functions environment evolves.
  • Administrative access: Ensure that at least one administrator group retains compartment-level access (without resource-level restrictions) to manage all functions and troubleshoot access issues.

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 from the Compartment dropdown list.

  4. In the Applications list, identify the applications that specific user groups should access and note their OCIDs. Click on an application name to view its details, and copy the OCID value from the Application information section.

  5. If you need function-level restrictions, click on the application name, then select a function to view its details, and copy the function OCID from the Function information section.

  6. Navigate to Identity & Security console available at https://cloud.oracle.com/identity/.

  7. In the left navigation panel, under Identity, choose Policies.

  8. Choose the OCI compartment that contains the Functions-related policy you want to modify from the Compartment dropdown list.

  9. Click on the name (link) of the IAM policy that you want to reconfigure (see Audit section part I to identify the right resource).

  10. In the Policy detail page, choose Edit policy statements to modify the policy.

  11. For each policy statement that lacks resource-level conditions, perform the following actions:

    1. For policies granting access to a single application, add a condition clause with the application OCID. For example, update:
      • Old statement: Allow group FunctionsInvokers to use fn-invocation in compartment cc-functions-compartment
      • New statement: Allow group FunctionsInvokers to use fn-invocation in compartment cc-functions-compartment where target.app.id = 'ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
    2. For policies granting access to multiple applications, use the ANY operator with multiple application OCIDs. For example:
      • Allow group FunctionsInvokers to use fn-invocation in compartment cc-functions-compartment where ANY {target.app.id='ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd', target.app.id='ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcdabcd1234abcd1234abcd1234abcd1234abcd1234'}
    3. For policies granting access to specific functions, use function OCIDs instead:
      • Allow group DataProcessors to use fn-invocation in compartment cc-functions-compartment where target.function.id = 'ocid1.fnfunc.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
    4. For management policies, apply the same resource-level conditions to manage statements:
      • Allow group FunctionsDevelopers to manage fn-function in compartment cc-functions-compartment where target.app.id = 'ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
    5. To edit a statement, click on the statement text, add the where clause with the appropriate condition, and save the changes.

  12. Choose Save changes to apply the updated policy statements with resource-level access controls.

  13. Verify the changes by testing access with users from the affected groups to ensure they can access the functions they need but cannot access functions outside their authorization scope.

  14. Repeat steps no. 9 – 13 for other IAM policies that contain Functions-related statements without resource-level conditions.

  15. Repeat steps no. 8 – 14 for each compartment, including the root compartment (tenancy), available within your Oracle Cloud Infrastructure (OCI) account.

Using OCI CLI

  1. Run fn application list command (Windows/macOS/Linux) to list Functions applications and retrieve their OCIDs for use in policy conditions:

    oci fn application list
	--compartment-id 'ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--all
	--query 'data[].{name:"display-name", id:id}'

  2. The command output should return application names and OCIDs:

    [
	{
		"id": "ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
		"name": "cc-web-function-app"
	},
	{
		"id": "ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcdabcd1234abcd1234abcd1234abcd1234abcd1234",
		"name": "cc-data-function-app"
	}
]

    Note the OCIDs of applications that specific user groups should access.

  3. If you need function-level restrictions, run fn function list command (Windows/macOS/Linux) to retrieve function OCIDs:

    oci fn function list
	--application-id 'ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--all
	--query 'data[].{name:"display-name", id:id}'

  4. Run iam policy get command (Windows/macOS/Linux) with the ID of the IAM policy that you want to reconfigure (see Audit section part II to identify the right resource):

    oci iam policy get
	--policy-id 'ocid1.policy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--query 'data'

  5. The command output should return the current policy configuration. Review the statements to identify which ones need resource-level conditions added.

  6. Create a JSON file (e.g., resource-level-policy-statements.json) containing updated policy statements with resource-level conditions using application or function OCIDs:

    [
	"Allow group FunctionsInvokers to use fn-invocation in compartment cc-functions-compartment where target.app.id = 'ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'",
	"Allow group FunctionsDevelopers to manage fn-function in compartment cc-functions-compartment where target.app.id = 'ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'",
	"Allow group FunctionsAdmins to manage functions-family in compartment cc-functions-compartment"
]

    This example shows resource-level conditions for invokers and developers (restricted to a specific application), while administrators retain compartment-level access.

  7. Run iam policy update command (Windows/macOS/Linux) to update the policy with resource-level access controls:

    oci iam policy update
	--policy-id 'ocid1.policy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'
	--statements file://resource-level-policy-statements.json
	--force

  8. The command output should return the updated policy configuration:

    {
	"data": {
		"compartment-id": "ocid1.tenancy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
		"defined-tags": {},
		"description": "Functions access policy with resource-level conditions",
		"freeform-tags": {},
		"id": "ocid1.policy.oc1..aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd",
		"lifecycle-state": "ACTIVE",
		"name": "cc-functions-access-policy",
		"statements": [
			"Allow group FunctionsInvokers to use fn-invocation in compartment cc-functions-compartment where target.app.id = 'ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'",
			"Allow group FunctionsDevelopers to manage fn-function in compartment cc-functions-compartment where target.app.id = 'ocid1.fnapp.oc1.ap-sydney-1.aaaabbbbccccddddabcd1234abcd1234abcd1234abcd1234abcd1234abcd'",
			"Allow group FunctionsAdmins to manage functions-family in compartment cc-functions-compartment"
		],
		"time-created": "2025-01-10T09:15:00.123000+00:00",
		"version-date": null
	}
}

  9. Verify the policy changes by testing access with users from the affected groups to ensure resource-level restrictions are properly enforced.

  10. Repeat steps no. 4 – 9 for other IAM policies that contain Functions-related statements without resource-level conditions.

References

Publication date Feb 24, 2026

Related OCI-Functions rules