Administrator guide

Administrators manage FunctionPilot from Administration in the portal (PortalUrl): connections, grants, roles, settings, the audit log, and the licence. Everything is stored in the stack's DynamoDB table in your account, and every change is written to the audit log.

#Roles

• Everyone who signs in without a role entry is a User, and sees no functions until a grant applies to them.
• Roles and grants match the user's email or groups. The email must be trusted: asserted by your SAML IdP, verified by your OIDC IdP (email_verified), or marked verified in the Cognito user pool (Identity providers).
• In Administration › Roles, choose User or Group, enter the email or the group name exactly as your IdP sends it, choose Administrator or User, and Save role. A role for a user wins over a role for one of their groups, so you can make a group administrators and keep one member a User. A change applies on the user's next request.
• You can't remove your own Administrator role. Grant it to at least one more person or group.

#The bootstrap admin

BootstrapAdminEmail (a stack parameter) is the bootstrap admin. The first person who signs in with that email is bound to it by their immutable user ID (the Cognito sub) and is always an Administrator, which prevents lock-out. The Roles page shows the entry as "Set by the stack (bootstrap admin)". The binding is recorded in the audit log (bootstrap.bind). Someone else who later signs in with the same email address but a different user ID is not the bootstrap admin.

#Recovering the bootstrap admin

Reset the binding when the bootstrap admin's user ID changes (the user was recreated, the IdP issues a new subject, or you switched IdentityProvider). Either:

• Use a different person: update the stack and change BootstrapAdminEmail. The first sign-in with the new email takes over the binding.
• Keep the same email: update the stack with BootstrapAdminEmail set to another address you can sign in with, and sign in with it once. Then set it back and sign in with the original email, which takes the binding over again.

If another Administrator can still sign in, they can simply grant the Administrator role to the person by email under Administration › Roles.

#Connections

A connection is one IAM role FunctionPilot assumes in one AWS account (Administration › Connections).

Screenshot

#Access levels

The access level of a connection's role is the ceiling for everyone, administrators included. Grants can narrow it per user or group but never widen it.

No access level lets FunctionPilot change a function's code, delete a function, or use IAM, CloudFormation, DynamoDB or S3 in the target account. Use ReadOnly for production accounts unless teams need to test there.

#Add a connection

Screenshot

1. Deploy the spoke role in the account (installation guide). How to connect another AWS account at the bottom of the page shows the steps, the template URL and an AWS CLI command.
2. Choose Add connection and enter:
   • Id: a short name used in links, for example production. It can't be changed later.
   • Name and AWS account id.
   • Access level: the same as the spoke stack's AccessLevel.
   • Role ARN: the spoke stack's RoleArn output. It must be in that account and under the /functionpilot/ path.
   • External ID: the same secret you gave the spoke stack (Generate makes a new one if you haven't deployed the stack yet). It is stored and never shown again; when you edit the connection, leave it empty to keep it.
   • Regions to show.
3. Save connection, then choose Test. The test assumes the role and lists the functions in each Region, and reports each Region's result or AWS error.

Each distinct AWS account counts against your plan's account limit, the hub account included (3 on Starter, 10 on Team, 50 on Business, unlimited on Enterprise). When the limit is reached, Add connection is disabled. Deleting a connection makes FunctionPilot stop using the role and makes grants on it stop applying; the role stays in the account until you delete its stack.

#Grants

A grant gives a user or a group permissions on the functions whose names match patterns, on a connection (or all) in some Regions (or all) (Administration › Grants). A new grant, or a change, applies on the user's next request.

Screenshot

Screenshot

• A user's permissions on a function are the union of every grant that matches them, through their email or any of their groups, capped by the connection's access level. The form shows Above ReadOnly (or the level) next to a permission the chosen connection can't allow.
• Matching functions previews which loaded functions the patterns match. Functions created later that match are covered automatically.
• Seeing environment variable values is a separate setting (see Settings), not a permission.
• A user with no matching grant gets "Function not found" for that function: FunctionPilot doesn't reveal that it exists.
• Grants don't apply to people working with personal AWS access; AWS decides for them.

#How grants are enforced

Grants are enforced twice. FunctionPilot checks them on every request, and every AWS call runs with temporary credentials that a per-request session policy limits to exactly the actions and function ARNs the user's grants allow. Even if FunctionPilot's own check had a bug, AWS would refuse anything outside the grants. Every session carries the user's email as its source identity, so CloudTrail in each account names the person.

If someone's grants on one function would make a session policy larger than AWS allows, FunctionPilot refuses the request ("too many grants") rather than widening it. Combine grants: use groups, and patterns such as orders-* instead of many single names.

Examples:

#Settings

Administration › Settings:

Screenshot

#Personal AWS access settings

Team and above. These turn on personal AWS access, where people act with their own AWS permissions instead of grants. The stack parameters IdentityCenterStartUrl, IdentityCenterRegion and PersonalAccessKeys set the first values; from then on the settings here apply.

With both methods off, everyone works through grants on your connections again. People can always disconnect a stored session, whatever the settings.

#Audit log

Administration › Audit log lists events by UTC day, newest first, with the time, the actor, the action, the target and the source IP. Open an event for its details. Filter this page searches the events shown.

Screenshot

Events are kept for your plan's audit days: 30 on Starter, 90 on Team, 365 on Business and 3,650 on Enterprise. Each event is also written as a JSON line ("kind": "audit") to the API's log group, /aws/lambda/<NamePrefix>-api, kept for the stack's LogRetentionDays, so you can forward it to your SIEM.

For a full trail, CloudTrail in each account records every Lambda, CloudWatch and Logs call FunctionPilot makes, with sourceIdentity set to the user's email.

#Licence and about

Administration › Licence and about shows your licence, your plan, CloudWatch usage and the installed version.

Screenshot

#Licence

FunctionPilot reads your AWS Marketplace licence from AWS License Manager in the hub account. The page shows the status, the plan, the entitlements, when the licence is valid until and when it was last checked. Check licence now reads it again (FunctionPilot otherwise rechecks every few minutes).

Without a valid licence every page except this one says a licence is required. Nothing is deleted; subscribing again unlocks FunctionPilot.

#Plan

What your plan includes lists the limits and features of your plan:

Features your plan doesn't include show a plan badge, and FunctionPilot refuses them. To change plan, see Upgrading.

#CloudWatch usage

FunctionPilot's own AWS cost is mostly CloudWatch: metrics are billed per metric returned and Logs Insights per GB scanned. The CloudWatch usage card shows the last 30 days: the estimated cost, what the shared cache saved, the cache hit rate, the metrics requested and the data Insights scanned, with a chart of metrics requested from CloudWatch and served from the cache per day. The estimates use list prices (about $0.01 per 1,000 metrics and $0.005 per GB scanned); your AWS bill is the record. To lower the cost, raise Metrics freshness in Settings.

#Version and updates

The version card shows the installed version and, when update checks are on (UpdateChecks), the latest release, its summary and release notes, whether it is a security release, the oldest supported version, and How to upgrade with the template URL and an AWS CLI command. A banner on the Administration pages announces a newer release once. See Upgrading.