Having new team members join a project is a normal process, and handling the process of an employee leaving a team (or even the company) should be, as well.
In the following post, we discuss how to remove a user from an IBM Cloud account and look into what additional tasks should be performed to maintain security.
Note: This blog post only gives a general idea and does not cover all situations and details.
Remove a user from an IBM Cloud account
When an employee leaves a project team or the company, it means you must remove access to resources. On IBM Cloud, resources are organized by account and, within an account, by additional organizational types like resource groups and regions.
Similar to other activities, you can remove a user from an account either through the browser UI, a CLI command, or by an API call. Here is an example of using the CLI command:
Only an account owner or privileged users can perform that action. You can find details in the documentation on removing users from an account.
A few things are important to note
- After a user is removed from an account, the user no longer can log into the account, switch to the account (when being logged in to another account), or access the account resources. All related access privileges are removed as part of the removal processing.
- The IBM Cloud IAM access management follows the model of eventually consistent. It means that changes are process asynchronously. Therefore, the full impact of the removal processing is not directly visible and only will be after it has been propagated throughout the system. The user in question may be logged in and some partial access might still be possible until access tokens have expired.
- Resources which the user created remain in the account. Thus, provisioned services, deployed apps, or instantiated VMs continue to work.
- Removing a user from an account does not remove the user’s associated IBMid.
If the user in question is the account owner, a different process is needed; in that case, the account ownership needs to be transferred.
Rotate and clean up related credentials
It is a good practice—and often mandated—to rotate credentials for apps and services to which the departing employee had access. See my previous blog on how to enhance security by rotating service credentials for a general introduction and for details on solutions implemented with IBM Cloud Functions and Cloud Foundry.
My blog on how to use a delivery pipeline to rotate app credentials looked into automation and apps using the IBM Cloud Kubernetes Cloud Service.
Many administrators use SSH keys to access virtual servers. Thus, if the leaving user was privileged to log into compute resources, those keys need to be removed.
Track activities and use notifications
Once you remove the user from the account and rotate credentials, it is back to “trust, but verify.”
Use Activity Tracker with LogDNA to monitor account activity. Regularly search for, e.g., login events by that removed user. There should be none. You can either search through the LogDNA UI or make use of the API and search from the command line.
Another option for continued monitoring of account activity is to set up alerts within LogDNA. For details on how to set up a Slack integration for LogDNA read this blog on account auditing using Activity Tracker with LogDNA.
Summary
When an employee leaves, the offboarding process begins. It involves cleaning up accounts and making sure that only authorized access to resources is possible. This involves cloud services, and we have shown that it is easy to remove a user from an IBM Cloud account.
Thereafter, related credentials should be changed—this is possible with zero-downtime to production systems. All that is left is to maintain regular security monitoring. It is simple to make use of activity logs by searching them or setting up security alerts.
If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.