Track API key usage by combining IBM Cloud IAM and LogDNA search

Which key is still in use...?

Recently, I blogged about tracking account activity from the command line. I showed you how to search IBM Cloud Activity Tracker with LogDNA records using a Python script. Today, I discuss how to combine the IAM Identity Services API with the LogDNA search to track usage of API keys. The goal is to find out whether API keys for a user or service ID were recently used. If they were not used for long, they might be up for deletion.

IBM Cloud APIs

IBM Cloud offers many APIs for its services as well as for the core platform. One of the APIs offered for the core cloud platform is the IAM (Identity and Access Management) Identity Services API. Using that REST interface it is possible to create, list or delete API keys for users and service IDs and to create or delete service IDs.
The same interface can also be used to generate an access token based on a valid API key. In short, managing API keys starts with an API key.

From API key to usage report

To get to the usage report, the script starts by turning an API key into an IBM Cloud access token. The token needs to be provided for all calls to the IAM API. Next, the script retrieves details about the provided key. This is needed to have the account ID as parameter to other calls.
With the token and account information in place, the next step is to obtain the list of API keys for the current user. The result is then turned into LogDNA searches. For each API key, the script produces the number of found activity records and the timestamp of the most recent usage. All the results are turned into a single JSON document.

With the same approach, the list of service IDs is requested and for each ID the related service ID API keys. Similar to the user API keys, the script composes a LogDNA search for each item and adds the result to the JSON report. A sample run of the script and its output might look like this:

./trackAPIKeys.py creds.json
{
  "generated_at": "2019-08-16 16:19:23.622914",
  "apikeys": [
    {
      "name": "CMtest",
      "created_at": "2018-07-25T08:18+0000",
      "numlogs": 0
    },
    {
      "name": "API Key for secure-file-storage-20190722111743812",
      "created_at": "2019-07-22T11:18+0000",
      "numlogs": 64,
      "lastEventTime": "2019-07-22T11:18:42.85+0000"
    },
    {
      "name": "API Key for secure-file-storage-henrik-fra04",
      "created_at": "2018-10-05T09:49+0000",
      "numlogs": 0
    }
],
  "serviceids": [
    {
      "name": "15xxxxfa-yyyy-4e2d-yyyy-f87xxxxc5a18",
      "created_at": "2019-06-20T08:48+0000",
      "keys": [
        {
          "name": "15xxxxfa-yyyy-4e2d-yyyy-f87xxxxc5a18",
          "created_at": "2019-06-20T08:48+0000",
          "numlogs": 0
        }
      ]
    },
    {
      "name": "Kube ID Henrik",
      "created_at": "2018-07-25T08:39+0000",
      "keys": [
        {
          "name": "Test2",
          "created_at": "2018-09-07T12:19+0000",
          "numlogs": 0
        },
       {
          "name": "new",
          "created_at": "2019-08-06T10:24+0000",
          "numlogs": 2,
          "lastEventTime": "2019-08-06T10:26:17.46+0000"
        },
      ]
    }
  ]
}

Get started

Now, with the understanding of the overall flow, check out the KeyTracker script available in the LogDNA search repository on GitHub.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.