Ensure that your Oracle Cloud Infrastructure (OCI) IAM policies enforce separation of duties by clearly distinguishing between function management permissions and function invocation permissions. Users or groups that only need to invoke functions should be granted the use fn-invocation permission, while users responsible for creating, modifying, or deleting functions and applications should be granted manage fn-function and manage fn-app permissions. The overly permissive manage functions-family verb grants both management and invocation capabilities simultaneously and should only be used for administrative roles that genuinely require both types of access. Implementing this separation prevents scenarios where application users who only need to trigger business logic functions could accidentally or maliciously modify function code, delete critical functions, or alter application configurations. This separation of duties is a fundamental security control that reduces the risk of unauthorized modifications, supports compliance requirements for role-based access control, and enables clear audit trails showing who performed management operations versus invocation operations.
Security Separating function management permissions from invocation permissions enforces the principle of separation of duties, which is critical for maintaining security and operational integrity in serverless environments. When users have both management and invocation permissions through the manage functions-family verb, they can not only execute functions but also modify function code, change function configurations, delete functions, and alter application settings. This creates significant security risks including the potential for privilege escalation (users modifying functions to gain additional permissions), unauthorized data access (altering functions to exfiltrate data), service disruption (accidental or malicious deletion of critical functions), and compliance violations (lack of proper separation between operational and development roles). By implementing separate policies where invokers have only use fn-invocation and developers/administrators have manage fn-function and manage fn-app, organizations create clear role boundaries that align with job responsibilities. Application users can invoke functions to perform business operations without the risk of modifying the underlying serverless infrastructure, while developers and operators can manage the function lifecycle without necessarily having the ability to invoke every function in production. This separation also improves auditability by making it clear which users performed which types of operations, supports compliance frameworks that require role separation (such as SOC 2 and PCI-DSS), and reduces the attack surface by ensuring that compromised invoker credentials cannot be used to modify function code or infrastructure.
Audit
To determine if your OCI IAM policies properly separate function management from invocation permissions, perform the following operations:
Remediation / Resolution
To implement proper separation of function management and invocation permissions in your Oracle Cloud Infrastructure (OCI) IAM policies, perform the following operations:
Important considerations before implementing role separation:- Plan the role structure: Before modifying policies, clearly define which users need invocation-only access and which need management access. Common patterns include:
- Invokers/Application Users: Need only use fn-invocation to execute functions as part of application workflows.
- Developers: Need manage fn-function and manage fn-app to develop and deploy functions, but may not need invocation permissions in production.
- Administrators: May need manage functions-family for full administrative control, but this should be limited to a small admin group.
- Create separate user groups: Organize users into distinct groups based on their roles (e.g., FunctionsInvokers, FunctionsDevelopers, FunctionsAdmins) to enable clear policy assignments.
- Test policy changes: IAM policy changes take effect immediately. Test new policies in a non-production environment first to ensure users can still perform their required tasks.
- Communicate with users: Notify users before reducing their permissions, as some may currently have management permissions they don't actually need but have become accustomed to.
- Document role definitions: Maintain clear documentation of which group has which permissions and the rationale for each permission grant.
- Consider resource-level restrictions: For invokers, consider adding resource-level conditions (such as where target.app.id = '<application-OCID>') to further restrict which functions they can invoke.
- Policy precedence: When multiple policies apply to a user, OCI uses the most permissive policy. Ensure that users aren't members of multiple groups with conflicting permission levels.
References
- Oracle Cloud Infrastructure Documentation
- Controlling Access to Invoke and Manage Functions
- Creating Policies to Control Access to Network and Function-Related Resources
- Controlling Access
- Getting Started with Policies
- Policy Syntax
- Managing Policies
- Oracle Cloud Infrastructure CLI Documentation
- compartment list
- group list
- group create
- policy list
- policy get
- policy update