Lambda Cloud: give automatic jobs their own access

Give repeated work its own owner

If a scheduled business job on Lambda Cloud runs using an employee’s access key, put an administrator in charge of reviewing that arrangement. A new account option lets the software have its own identity and a more limited set of permissions.

Lambda announced the controls on November 4. They are part of its identity and access management system, which determines who can use cloud resources and what they can do. This is Lambda’s cloud computing service, not Amazon’s AWS Lambda product.

Previously, access keys carried their owner’s full permissions. A key is a secret used by software to sign in. A routine job could therefore have more access than its actual work required.

Read the announcement: Lambda: November 4 access-management release.

Separate people from automatic jobs

The new service identities are accounts for software. Each can have its own keys and assigned roles, which are bundles of permissions. Groups let an administrator manage access for several people or jobs together.

Using a resource requires both membership of the workspace containing it and a role that permits the action. The effective-access view shows roles inherited through groups as well as those assigned directly.

Lambda’s documentation says adding an identity to a workspace grants Workspace Member by default. Review that default and all inherited roles before assuming the job’s access is restricted.

For the business owner, that creates a clearer handover when someone changes role or leaves. The job can have an accountable team owner without depending on one person’s login. The administrator still needs to maintain its access and keys.

Keep the switch controlled

Existing accounts and keys keep working. Turning on the new controls does not remove a personal key already stored in a script. That change needs to be planned and checked.

A service identity can hold two keys at once, helping the administrator replace one while the other remains available. Lambda also supports key expiry and revocation. Before deleting an old personal key, check whether other jobs still use it.

Lambda says the controls are free; the computing resources you run still cost money. Allow time for the administrator to review permissions, update the job and confirm that normal work continues.

Start with one known job

Our perspective: existing Lambda customers now have a practical reason to review shared access. Start with a job whose result you can verify, then use what you learn to plan the remaining changes. This release alone is not a reason to move an app to another cloud.

We have not tested these controls. The administrator should confirm both what a job can do and what it must be prevented from doing.

1. This week, list one automatic job, its business owner and the personal key it currently uses.
2. Have the administrator assign a separate service identity the required workspace access and roles.
3. Test the required work and a harmless action that should be denied before switching the regular job.
4. After confirming the switch and checking other dependencies, revoke the old key and record who maintains the replacement.