Administrator guide

Administrators manage Cloud Certainty Memora from Administration in the portal (PortalUrl): connections, connectors, grants, roles, ElastiCache users and user groups, settings, usage, the audit log, and the licence. Everything Memora stores is in the stack's DynamoDB table in your account, and every change is written to the audit log.

Administration has the pages Connections, Connectors, Grants, Roles, Cache users, Settings, Usage, Audit log and Licence and about. How Memora signs in to each cache's data is set on the cache's own Data access tab (Data access).

#Roles

• Everyone who signs in without a role entry is a User, and sees no caches 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, under Grant a role, choose User or Group, enter the email or the group name exactly as your IdP sends it (group names are case-sensitive), choose Administrator or User, and choose 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. 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 Memora assumes in one AWS account, with the Regions it covers and an access level (Administration › Connections).

#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.

Use Read for production accounts where people should look but not touch, Operate where teams fix data and operate caches, and Full where teams create and reconfigure caches through Memora, or where you want Memora to set up IAM data access. A good pattern is to start at Full while you set up data access on your caches, then lower the account to Operate.

#Add a connection

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. Set TrustedPrincipal to the hub stack's SpokeTrustedPrincipal output (both role ARNs, comma-separated) and choose an ExternalId secret of 16 or more characters.
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, arn:aws:iam::<account>:role/memora/<RoleName>. It must be in that account and under the /memora/ path.
   • External ID: the same secret you gave the spoke stack. 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, for each Region, reports how many caches it found, or the AWS error.
4. To read and change data in that account, deploy a connector in each VPC that holds caches.

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 Memora stop using the role, and grants on it stop applying; the role stays in the account until you delete its stack.

#Connectors

A connector is a pair of Lambda functions (read and write) in one VPC. It is the only part of Memora that talks to your caches, so the key browser, the workbench, memory analyses, the monitor and bulk jobs work only on caches a connector can reach (Administration › Connectors). Without one, Memora still shows caches, metrics and backups and operates them.

• The local connector comes from the hub stack (its ConnectorSubnetIds and CacheSecurityGroupId parameters) and can't be changed here.
• Others come from the connector template (connector.yaml), one per VPC, in any account and Region of a connection. Deploy a connector gives a quick-create link with the hub's details filled in, and the steps (installation guide).
• Register connector with an Id (used by a cache's data access to name it; it can't be changed later), a Name, the Connection and Region it runs in, the VPC id of the caches, and the Read function ARN and Write function ARN (the stack's ReadFunctionArn and WriteFunctionArn outputs). The ARNs must be in the connection's account and Region and named memora-connector-<name>-read and -write. One connector per VPC.
• Test invokes both functions with the connection's role (it doesn't sign in to any cache) and shows each function's version. The write function answers only on Operate and Full connections.

Each connector card lists the caches whose data access uses it. Data access without a connector lists caches whose data access names a connector that is no longer registered, or that are in a VPC without one. Memora uses the connector a cache's data access names, or else the connector registered for the cache's connection, Region and VPC.

Deleting a connector makes Memora stop using its functions; its stack stays in the account until you delete it. After you upgrade the hub, update each connector stack's Version parameter (Upgrading).

#Grants

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

What the patterns match previews the caches the patterns cover in each Region, and Try a key tells you whether a key is covered by the key patterns. Caches created later whose ids match are covered automatically.

Screenshot

write and operate are independent: a developer may change data without being able to reboot a cache, and an operator may scale a cache without seeing its data (operate doesn't include read). ElastiCache users and user groups are for administrators only.

#How grants combine

• A user's permissions on a cache are the union of every grant that matches them, through their email or any of their groups, whose connection, Region and patterns match the cache, capped by the connection's access level and the plan.
• A user with no matching grant gets "not found" for a cache: Memora doesn't reveal that it exists. A cache they can see but not use in that way answers "forbidden".
• Administrators have every permission on every cache and every key, still bounded by each connection's access level and the plan.

#Key patterns

Business plan and above. A grant's key patterns limit its read and write to matching keys; a person's key patterns on a cache are the union over their grants. With patterns other than every key:

• the key browser lists only matching keys, and analyses and bulk jobs touch only matching keys;
• every key a command names must match, or the command is refused before it reaches the cache;
• commands that can reach keys they don't name are refused: EVAL, EVALSHA, FCALL and their read-only forms, KEYS, SCAN typed in the workbench, RANDOMKEY, FLUSHDB, FLUSHALL, SWAPDB, MOVE, COPY with DB, SORT with BY or GET, and every Pub/Sub command;
• an analysis by that person covers only their keys and is shown only to them and administrators.

view, operate and manage are not limited by key patterns. Key patterns are enforced by Memora (the API and again the connector), not by the cache: every Memora user of a cache signs in as the same memora-read or memora-write. If the cache itself must enforce a key boundary, give that team its own cache, or narrow the access strings of memora-read and memora-write (for example ~cart:*), which then applies to everyone using Memora on that cache. On a lower plan, grants with key patterns stay in force and can be deleted, but not changed.

#How grants are enforced

Grants are enforced by Memora on every request, and every AWS call runs with temporary credentials (15 minutes) that a per-request session policy limits to the person's grants: operational and management actions only on the ARNs of the granted caches, and invoking only the connector function the request needs (the read function for read, the write function only for write and operate). For data, the cache's own ACL is a third layer: the read function signs in as memora-read, which can only read. A person without write can't change data even if Memora had a bug.

ElastiCache's describe actions have no resource-level permissions, so the session for reading cache descriptions can describe any cache in the Region; Memora asks only for the person's caches and filters every answer, so nobody sees a cache they have no grant on.

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

#Check access

Check access, at the bottom of Grants, shows what someone may do on one cache: enter a User email, their Groups (as your IdP sends them), the Connection, Region and Cache id, and choose Check access. It shows the Effective permissions, what was Removed by the connection (its access level), the Keys they may read and Keys they may change, their Role, and the Grants that matched.

#Examples

#Data access

How Memora signs in to a cache's data is set per cache, on the cache's Data access tab, by anyone with manage on it. Memcached has no users or passwords, and Memora's data tools work with Valkey and Redis OSS only.

A cache with neither an AUTH token nor a user group works without any set-up. A cache with authentication needs data access set up first; until then its data tabs say so.

Screenshot

#IAM data access

Set up IAM data access (needs manage and a connection with Full access) checks the cache's engine, encryption in transit and user group, then:

• creates the ElastiCache users memora-read and memora-write in the cache's Region if they are missing (IAM authentication, the cache's engine); existing users keep their settings;
• adds them to the cache's user group (the group shows modifying while ElastiCache applies the change; other users keep working);
• stores IAM data access for the cache.

The users get these access strings:

• memora-read: on ~* &* -@all +@read +@connection +info +slowlog|get +slowlog|len +client|list +client|info +memory|usage +memory|stats +latency|latest +command +dbsize +scan +type +ttl +pttl +object|encoding +object|freq +object|idletime +subscribe +psubscribe +ssubscribe +unsubscribe +punsubscribe +sunsubscribe
• memora-write: on ~* &* +@all -@dangerous +info +slowlog +client|list +client|info +client|kill +memory|usage +memory|stats +latency|latest +command +keys, plus +flushdb +flushall only when Allow FLUSHDB and FLUSHALL is on in Settings when the user is created.

The read function's role may connect only as memora-read, and the write function's only as memora-write. A cache without a user group can't use IAM: create a user group with a default user and add it to the cache (a change the cache owner should schedule), or use secrets. Once data access is set up, you can lower the connection to Operate.

#Secrets

For caches with an AUTH token or users with passwords, create two secrets in the cache's account and Region and tag them so only the matching connector function can read them. A secret holds {"username": "...", "password": "..."}, {"password": "..."} or the token as plain text:

aws secretsmanager create-secret --region eu-west-1 --name memora/orders/read \
  --secret-string '{"username":"orders-memora-read","password":"<password>"}' \
  --tags Key=memora:access,Value=read
aws secretsmanager create-secret --region eu-west-1 --name memora/orders/write \
  --secret-string '{"username":"orders-memora-write","password":"<password>"}' \
  --tags Key=memora:access,Value=write

Then, under Change data access, choose Secrets Manager, enter the Read secret ARN and Write secret ARN, and Save data access. Give the read user a read-only access string (the Memora read user preset under Cache users is a good start), so the cache refuses writes from it. With a single AUTH token, both sides share one secret: the read and write split is then Memora's only, and the tab says so. The connector's subnets need a route to Secrets Manager (a NAT gateway or an interface endpoint); the connector caches secret values for 5 minutes, in memory only. The API, the browser and the tables never see them.

#Other settings

Change data access also lets you name the Connector for a cache (leave empty to use the connector registered for its VPC), set a Port other than the cache's, or Remove the stored data access (ElastiCache users and secrets are not deleted). Keep the IAM users memora-read and memora-write: the connector functions' roles may connect only as those two users. Test connection asks the connector to sign in and shows the engine, the user it signed in as and the nodes it reached.

#Cache users

Administration › Cache users manages ElastiCache users and user groups, which control who can sign in to Valkey and Redis OSS caches with role-based access control and which commands and keys they may use. They belong to an account and Region, not to one cache: choose the Connection and Region. Only administrators manage them, and only on connections with Full access.

• Users lists each user's id, name, engine, status, authentication, access string and user groups. Create user (or Edit) sets the user id, the engine, the authentication and the access string:

  • IAM: a short-lived IAM token, no password; needs Valkey 7.2 or Redis OSS 7.0 or later and encryption in transit, and the user name equals the user id;
  • Password: one or two passwords (two let you rotate without downtime), 16 to 128 characters. Memora sends them to ElastiCache and never stores, logs or shows them again, so keep them in your secret store;
  • No password: anyone who can reach the cache can sign in as this user; use it only with a narrow access string, such as off -@all for the default user.

  Start from a preset fills the access string: Read only, Read and write, Memora read user or Memora write user.

• User groups lists each group's users and caches. Create user group (or Edit) chooses its users; every user group needs a user named default.

ElastiCache applies changes in a minute or two. It refuses to delete the default user, users still in a user group, and user groups a cache still uses. Changing memora-read or memora-write can stop the key browser and workbench on caches that use them; the page warns you.

#Settings

Administration › Settings:

Screenshot

Choose Save settings, or Discard changes. Leave Allow FLUSHDB and FLUSHALL and Record command values off unless you need them.

#Usage

Administration › Usage shows what people did through Memora, counted per UTC day, over 7, 30 or 90 days: Commands run, Write commands, Key browser reads (scans, key views and Pub/Sub samples), Memory analyses, Bulk job keys and Cache changes (backups, scaling, reboots, settings, engines, parameters, users and other changes to caches), with charts per day. On Business and above, Top users shows every counter for the 50 people who ran the most commands.

Usage is kept for 400 days. It counts what people do through Memora only; what your applications do on your caches isn't counted here (the fleet's metrics include it).

#Audit log

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

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 to the API's CloudWatch 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 ElastiCache, CloudWatch and EC2 call and every connector invocation Memora makes, with sourceIdentity set to the user's email and the role session name mm-<email>. Calls made by a bulk job carry the job owner's email. Who ran which commands on which cache is in History (administrators can choose Everyone).

#Licence and about

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

#Licence

Memora 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 (Memora otherwise rechecks every 10 minutes).

Without a valid licence every page except this one says a licence is required. Nothing is deleted; subscribing again unlocks Memora. Your caches are not affected: they run in ElastiCache whether Memora is licensed or not.

#Plan

What your plan includes lists the limits and features of your plan, and Compare plans shows all four:

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

#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 (View update steps). See Upgrading, including updating each connector stack's Version after the hub.