Replace tokens before they expire

As of September 3, 2024 any new access tokens that you create will not expire. They will refresh automatically without expiring until you decide to revoke the token.

Any tokens created before September 3, 2024 will still expire. You need to replace these tokens before their expiry date to avoid losing access to EdgeKV from an EdgeWorker ID. You then need to update your edgekv_tokens.js file(s) with the new token and upload and activate the associated EdgeWorker bundles. Your EdgeKV calls will fail if an expired token is not replaced in time, and you will receive a 401 error when using an expired token.

To monitor the expiry date of your access tokens created before September 3, 2024, you can use the EdgeKV CLI List and Retrieve commands or the EdgeKV List and Retrieve management APIs.

Store access tokens securely

Rely on Akamai to keep your access tokens stored securely, and only retrieve them as needed. Do not store access tokens in your own systems, except in transient storage. For example, you can temporarily store an access token on your local filesystem until you have created and uploaded an EdgeWorker bundle, after which we recommend that you delete the local copy.

Comply with your corporate security standards

If you have stringent corporate security requirements, consider implementing one or more of the following best practices to further restrict access to your EdgeKV data:

Limit access token permissions

Be specific with the namespace permissions in the token. If, for example, your EdgeWorkers code does not require delete or write access to your “marketing” namespace, grant it read-only access in the token:

edgekv create token token1 --staging=allow --production=allow \
    --namespace=default+rwd,marketing+r --expiry=2021-12-31

This reduces the likelihood of inadvertent writes or deletes being made to the database.

Separate tokens

Another good practice is to use single-purpose tokens: create a separate token for every unique use case for a given namespace. This provides an additional layer of isolation.

Notifications

This feature notifies you when your access tokens are nearing expiration. Be sure to subscribe to those notifications so you can replace your tokens well ahead of expiry. Any tokens created using the enhanced token workflow will no longer expire.

Limit access tokens to a namespace

To add another layer of security to EdgeKV you can specify an access group for each namespace. This access group can then be restricted to specific individuals in your organization.

You should associate any EdgeWorker IDs that you create with the same access group as the namespace it uses. This prevents unauthorized users from downloading the token indirectly via the EdgeWorkers code bundle.

For example, if only EdgeWorker ID 1234 requires access to the “marketing” namespace you should first create access group 100 specifically for the marketing use case. Then create EdgeWorker ID 1234 under group 100. You should also create the marketing namespace under group 100. This prevents individuals that don't belong to group 100 from retrieving the access token(s) associated with the marketing namespace via the EdgeKV tools, or indirectly by downloading the code bundle.

For more information about groups refer to the Identity and Access Management documentation.

Lock an access token to specific EdgeWorker IDs

You can lock an access token to one or more specific EdgeWorker IDs. For example, if only EdgeWorker ID 1234 needs to access the namespace “marketing” you would:

Create a token specific to that use case.
Restrict the EdgeWorker ID in the token permissions list.
Only include the “marketing” namespace in the permissions.

edgekv create token mkt_token1 --staging=allow --production=deny \
    --ewids=1234 --namespace=marketing+r --expiry=2021-12-31

Coming soon - Isolate your staging and production environments

In the future you'll be able to use your CI/CD system to separate your production and staging workflows. This will let you create separate API client credentials for your developers and grant them permission to access only to the staging environment, while creating another API client credential for your CI/CD system and granting it permissions to access to your production environment.

You should also consider creating separate tokens for the production and staging environments whereby the staging one can be retrieved by developers and the production one can be retrieved by the CI/CD system.

Combining these will restrict your developers access to only the staging environment, while allowing your CI/CD system to access production.

To create a specific tokens for the staging and production environments:

edgekv create token mkt_token1_prd --staging=deny \
    --production=allow --ewids=1234 \
    --namespace=marketing+r --expiry=2021-12-31
edgekv create token mkt_token1_stg --staging=allow \
    --production=deny --ewids=1234 \
    --namespace=marketing+r --expiry=2021-12-31