transiliencecloud onboarding
AWS · optional human access

Invite an engineer. Not a shared identity.

Give an approved person the access they need—without sharing passwords, access keys, or your administrator account.

Optional — Human access

Prepare an engineer-access request.

This creates a local, non-secret request for your AWS administrator. It does not send email, create a user, or assign permissions.

Fields stay in this page’s memory, not local storage. Downloads remain on your device. No password or access key belongs here.

This human-access path is separate from the OIDC assessment connector. Use a named Transilience engineer’s approved work email. Your administrator creates or provisions the person; this portal does not send an invitation or grant access.

  1. In IAM Identity Center → Settings, confirm your identity source. For an external identity provider, provision the engineer through that provider’s approved process instead of creating a duplicate local user.
  2. For the built-in Identity Center directory, open Users → Add user, enter the individual’s email, and select AWS’s email invitation option. AWS—not this website—sends the setup email. Current AWS documentation specifies a seven-day invitation window.
  3. Put the engineer in a customer-approved group. Assign that group only to the selected AWS accounts and a reviewed permission set. Use a short session duration, for example one hour.
  4. Require MFA through the configured identity source. Validate effective access with the engineer before marking the request complete.

AWS user invitations · Account and permission-set assignments

Choose the least access that answers the question#

Profile Appropriate use Important boundary
SecurityAudit Security configuration and posture review Recommended starting point; not an unrestricted log or data reader.
ViewOnlyAccess Basic resource visibility Intentionally narrower; may not support a full assessment.
ReadOnlyAccess Broader investigation approved by the customer Can expose service data and sensitive content; review every allowed service.

AWS-managed policies evolve. Review their current policy JSON and the permission set’s effective policies, including boundaries and account controls. Do not grant AdministratorAccess as a shortcut. Add narrowly scoped log, billing, or ECR permissions only after a separate need-and-scope review.

AWS IAM access best practices · SecurityAudit policy

Exception: an IAM console-only user#

Use this only when your customer cannot use federation and has approved the exception. IAM user creation is not an email invitation workflow.

  1. Create one named IAM user for the approved person; use your naming standard and approved read-only group/policy.
  2. Enable console access, require password change at next sign-in, and require MFA before routine use. Do not create an access key.
  3. Deliver the console sign-in URL and temporary password through separate approved secure channels. Never put the password in email, this portal, a Slack message, or the access-request download.
  4. Set an expiry/review date and record the exception owner. Disable the user when the engagement ends, remove any access keys, and review outstanding sessions.

The email in the request identifies the intended person; assigning an email-shaped IAM username does not make AWS send that person an invitation.

AWS console-password administration

Revoke and review#

Remove account/permission-set assignments and group membership when the engagement ends. For an external identity provider, remove the source identity’s access as well. Handle active sessions according to your incident/offboarding policy; deleting a user or password is not a blanket guarantee that all issued credentials are invalidated immediately.

Keep moving

Make the next step a confident one.

Verify the connection →

Find your next step.

Search runs locally. No queries leave your browser. Esc to close.