Design Flowcore IAM access

Flowcore IAM determines which identities may perform actions on tenant resources. The model separates reusable permission definitions from the users, keys, and roles that receive them.

The main concepts are:

• Actions describe permitted operations.
• FRNs identify the Flowcore resources to which actions apply.
• Policies combine actions and resource scope.
• Policy bindings attach policies to identities or roles.
• Roles group reusable access.
• Role associations or bindings assign roles to identities.
• Permission queries show effective access.

Start with the required workflow

Do not begin by cloning an administrator role and removing a few obvious permissions.

Describe the application's operations first. For an order producer, that might be:

• Resolve one configured tenant and data core
• Publish order.placed.0 and order.cancelled.0
• Read no event history
• Manage no IAM resources
• Restart no pathways
• Delete no resources

Translate those operations into the smallest available actions and FRN scope.

Understand Flowcore Resource Names

An FRN identifies a Flowcore resource or hierarchy for IAM evaluation. It can scope a policy to a tenant, data core, flow type, event type, pathway, or another supported resource domain.

Use the narrowest practical FRN. A policy scoped to one event type has a smaller impact than a tenant-wide wildcard.

Do not construct FRNs from memory. Use the format and resource types supported by the current IAM schema or SDK and verify them through effective-permission queries.

Broad wildcard FRNs can be appropriate for a platform administrator, but they should be exceptional for application keys.

Write focused policies

A policy should have one explainable purpose, such as:

• Publish selected commerce events
• Read customer-support event history
• Manage one application's Data Pathway
• Provision event resources in development
• Administer tenant IAM

Avoid a single policy named application-access that mixes ingestion, sensitive reads, IAM updates, and deletion.

Focused policies are easier to review, reuse, revoke, and audit.

Use roles for common human access

Roles group access used by several users, such as:

• Event developer
• Support investigator
• Platform operator
• Security auditor
• Tenant administrator

Assign users to roles rather than duplicating equivalent direct policies for every person.

Keep role names and descriptions tied to responsibilities, not individuals. Review role membership regularly.

When a role becomes obsolete, remove its associations and archive it through the supported lifecycle. Do not leave ambiguous dormant roles available for later accidental assignment.

Use narrow policy bindings for service keys

A specialized service key may need a policy narrower than a general role.

Directly binding a focused policy can make the service's purpose clear and avoid expanding a reusable role for one exception.

If many services need exactly the same permission set, a service role can reduce policy sprawl. Keep environment and resource boundaries explicit.

Do not attach human administration roles to application keys merely because it is convenient during development.

Separate duties

Split high-risk capabilities across identities when practical:

• Runtime publisher: ingest selected event types
• Projection consumer: read selected sources
• Provisioner: create and update resource definitions
• Pathway operator: inspect and restart specific pathways
• Security administrator: manage IAM
• Lifecycle administrator: truncate or delete resources

The runtime service should not be able to grant itself more access.

CI that applies manifests should not also possess unrestricted event-history and secret-read permissions unless the workflow truly requires them.

Manage IAM declaratively

Flowcore v2 IAM manifests use the iam.flowcore.io/v1 API group and supported kinds such as Policy, Role, PolicyBinding, and RoleBinding.

Store non-secret IAM resources in source control, run diff in pull requests, and apply through a protected environment.

A policy change is a security change even when the YAML diff is small. Review action additions, FRN broadening, new subjects, and deleted restrictions explicitly.

Do not include API key values or secret values in IAM manifests.

Use the SDK for administrative workflows

The SDK includes command families to:

• Create, list, get, update, and archive roles
• Create, get, update, and archive policies
• Link or unlink policies to users, keys, or roles
• Associate roles with identities
• Query effective permissions for users and keys

Place these commands behind trusted administrative services or tooling. Do not expose a generic IAM mutation endpoint to untrusted clients.

Record the requesting administrator, reviewed change, affected subject, and resulting resource IDs.

Verify effective permissions

Manifest intent and effective access can differ because an identity can receive permissions from multiple roles and policies.

After a change, query the effective permissions for the user or key and test the intended workflow.

Verify both positive and negative behavior:

• The application can perform required operations.
• It cannot read unrelated event types.
• It cannot request sensitive data without explicit grant.
• It cannot modify IAM.
• It cannot truncate or delete resources.
• It cannot operate unrelated pathways.

A successful happy-path request alone does not prove least privilege.

Avoid broad temporary permissions

Temporary administrator access often becomes permanent because no expiry or removal owner is recorded.

If elevated access is necessary during an incident or migration:

1. State the exact reason and resource scope.
2. Use a dedicated temporary role or binding.
3. Set an owner and removal time.
4. Monitor usage during the elevation.
5. Remove access immediately after the task.
6. Verify effective permissions returned to normal.

Do not modify a common application role temporarily; every associated identity would inherit the elevation.

Protect Sensitive Data permissions

Unmasked sensitive-data reads should not be part of broad developer, support, or application roles.

Grant them only to workflows that require protected fields, scope them to the relevant event resources, and audit use.

A user who can query ordinary event metadata may not need payload access. Design support tools to reveal only the minimum information needed for diagnosis.

Protect destructive operations

Truncation, deletion, delete-protection changes, and broad pathway restarts can affect audit and recovery.

Keep these actions out of normal runtime roles. Require explicit operator identity, reviewed scope, and auditable execution.

Delete protection is an additional lifecycle safeguard, not a replacement for IAM.

Audit meaningful IAM events

Capture changes to:

• Tenant membership
• Role creation, updates, associations, and archives
• Policy creation, updates, links, and archives
• Broad FRNs and wildcard actions
• API key creation and deletion
• Sensitive Data permissions
• Secret administration
• Resource truncation and deletion
• Data Pathway restart or reset access

Correlate the Flowcore change with a deployment, approval, or incident record. Avoid placing credential values in audit logs.

Monitor authorization failures

Repeated 401 responses can indicate expired or invalid authentication. Repeated 403 responses can indicate policy drift, a wrong tenant, or an attempted unauthorized action.

Alert on sustained failures for production services. Include the operation and non-sensitive resource scope so operators can distinguish an expired key from an unexpectedly narrowed policy.

Do not automatically grant broader access in response to a 403.

Review access over time

IAM accumulates as services, teams, and migrations change.

Review:

• Tenant users without current responsibilities
• Keys without active workloads
• Roles with no members
• Policies with no bindings
• Duplicate policies
• Broad wildcards introduced during incidents
• Sensitive Data grants
• Destructive permissions
• Cross-environment access

Archive obsolete IAM resources through the supported lifecycle and remove associations before they become a future ambiguity.

Continue with Protect configuration and sensitive event data.