“Ideas won’t keep. Something must be done about them.”
— Alfred North Whitehead
As most of you are aware, a Service Account is a special kind of user account that does not actually represent a physical human being. Most user accounts are for real users, but for automated interfaces and other integrations, many times you need credentials on external systems for use in your automation, and these accounts are not tied to any specific user. They are what is commonly referred to as a Service Account. In any give IT organization, there can be any number of Service Accounts for quite a wide range of services and technologies. Managing all of those accounts can become quite a burdensome task. There are a number of third party apps that provide tools for managing Service Accounts, but it occurred to me that the concepts are not all that sophisticated and it might be relatively simple to build a Scoped Application to handle the basic management of such accounts.
Here is what I am thinking: A single custom table could be built to store the account details. A second table could be used to store the various types of Service Accounts that could be stored in the main table, and one or more Service Catalog items could be used to manage the accounts. That’s not a huge number of artifacts, so it would appear that you could throw something together rather quickly. You know what I always ask myself: How hard could it be?
So let’s take a look at the lifecycle of an account. To create an account, you would request the account through the Service Catalog, providing all of the necessary information needed to set up the account on the appropriate technology. Let’s assume that the request has to be approved through the normal Service Request approval process, and that the requested item also has to be approved by the technology owner based on the type of account requested. Information on that second level of approval would be stored in the technology type table. Once approved, a fulfillment work flow would initiate, and once again we would turn to the technology type table to determine what specific fulfillment workflow should be executed to fulfill the request. Generally speaking, there would be two types of fulfillment, automated and manual. If the account creating and notification can be handled through automation or integration, then the entire process would be handled without human intervention. If not, one or more tasks would be generated and routed to the appropriate technical support resources. Either way, once the account was created and the requester notified, the requested item would be closed.
Creating the account is only half of account management process. It is never a good idea to just allow these things to live forever once they are created. There needs to be another catalog request process to manually terminate the account, and there should also be some process by which the requester reaffirms the need for the account on some predetermined interval. This Periodic Attestation process could, in fact, be another entirely different stand-alone app that could be used not only for this use case, but quite a number of others. That, however, would be an entirely different collection of blog entries, so we will leave that for another time. Still, we need a way to create an account, alter an account, get rid of account, and every so often, revisit the need for the account to continue to exist.
For our purpose, which is just to demonstrate the concept, we can just have two example technologies, one that we can automate, and one that we cannot (or more accurately, one that we choose to handle with a manual process). That will at least give us a demonstration of how things would work in either use case. Putting this all together, we will need to create the following:
- A Scoped Application
- A Master account table
- A technology type control table
- One or more Service Catalog items to create, alter, and terminate accounts
- A generic workflow for the catalog item(s)
- A type-specific workflow for each type of account in the type table
- Some kind of periodic workflow to ensure that the account is still needed.
It’s not a huge list of parts, but there is still a little bit there, so we will just point ourselves in that general direction, start pushing ahead, and see what we run into along the way. Maybe we will use the App Engine Studio for this one and see how far we can get with that. Regardless, it should be a fun little project, so we will jump right into it next time out.
