events: Emit lease expiration events

[swenson]

This is to gather feedback.

We might want to support other lease events, do different fields, or do these in a different way. And definitely add some tests.

This works by patching the lease expiration function so that it emit events when the lease timer fires.

I also investigated using a B-Tree to keep track of upcoming expirations, as it would probably be more scalable and allow us to fire events before leases expire, but it adds a fair amount of complexity and will require tuning.

These events look like this:

{
  "id": "expire-auth/approle/login/hc16d231ec9efbe88e9c49fc5d691f2617879146a13bb9b6a90ddc37d6ef02a84-1694728738",
  "source": "https://vaultproject.io/",
  "specversion": "1.0",
  "type": "*",
  "data": {
    "event": {
      "id": "expire-auth/approle/login/hc16d231ec9efbe88e9c49fc5d691f2617879146a13bb9b6a90ddc37d6ef02a84-1694728738",
      "metadata": {
        "client_token_type": "default",
        "expire_time": "2023-09-14T14:58:58-07:00",
        "id": "auth/approle/login/hc16d231ec9efbe88e9c49fc5d691f2617879146a13bb9b6a90ddc37d6ef02a84",
        "last_renewal_time": "0001-01-01T00:00:00Z",
        "login_role": "example-dot-com",
        "namespace": "",
        "path": "auth/approle/login",
        "version": "0"
      },
      "entity_ids": [
        "auth/approle/login/hc16d231ec9efbe88e9c49fc5d691f2617879146a13bb9b6a90ddc37d6ef02a84"
      ]
    },
    "event_type": "core/lease-expiration"
  },
  "datacontentype": "application/cloudevents",
  "time": "2023-09-14T14:58:58.456021-07:00"
}

[github-actions[bot]]

CI Results: All Go tests succeeded! :white_check_mark:

[github-actions[bot]]

Build Results: All builds succeeded! :white_check_mark:

[ncabatoff]

One problem I see here is that leaseIDs are sensitive information: if you know the leaseID, you can revoke or renew it. It's not unusual for the /sys/leases/revoke endpoint to be granted in policies, and sys/leases/renew is in the default policy. Renewal could be used as part of an attack, e.g.: I don't have access to this crashed application's token, but I do have a valid token from elsewhere, and I want to make use of the dynamic db credential I stole from the app.

[swenson]

One problem I see here is that leaseIDs are sensitive information: if you know the leaseID, you can revoke or renew it. It's not unusual for the /sys/leases/revoke endpoint to be granted in policies, and sys/leases/renew is in the default policy. Renewal could be used as part of an attack, e.g.: I don't have access to this crashed application's token, but I do have a valid token from elsewhere, and I want to make use of the dynamic db credential I stole from the app.

Perfect. This is exactly the sort of feedback I was looking for. :)

[swenson]

@ncabatoff I updated and standardized the lease event structure, and now emit them on creation, revocation, and renewal.

I believe I removed the sensitive data, but still have enough info for them to be actionable. Though, the data_path is not present, since I can't think of anything useful for it that doesn't involve the lease ID.

I also added a simple test.

Events look like:

{
  "id": "c07bf537-14cd-ad14-4d64-fcb5de6cf295",
  "source": "https://vaultproject.io/",
  "specversion": "1.0",
  "type": "*",
  "data": {
    "event": {
      "id": "c07bf537-14cd-ad14-4d64-fcb5de6cf295",
      "metadata": {
        "client_token_type": "default",
        "expire_time": "2023-09-20T11:08:55-07:00",
        "last_renewal_time": "0001-01-01T00:00:00Z",
        "login_role": "example-dot-com",
        "namespace": "",
        "path": "auth/approle/login",
        "token_accessor": "LkFUFhSYEKaV8YTEtimPn3cL",
        "token_entity_id": "41e53bca-bb1b-4ca9-09a5-184de1f39ce2",
        "version": "1"
      },
      "entity_ids": [
        "hvs.G615l6Y7vFExM3XlxRn71scQ",
        "41e53bca-bb1b-4ca9-09a5-184de1f39ce2"
      ]
    },
    "event_type": "core/lease-create"
  },
  "datacontentype": "application/cloudevents",
  "time": "2023-09-20T11:08:54.185301-07:00"
}

{
  "id": "7ebbbf41-f239-5b83-7f6f-a4bff055b2f8",
  "source": "https://vaultproject.io/",
  "specversion": "1.0",
  "type": "*",
  "data": {
    "event": {
      "id": "7ebbbf41-f239-5b83-7f6f-a4bff055b2f8",
      "metadata": {
        "client_token_type": "default",
        "expire_time": "2023-09-20T11:08:55-07:00",
        "last_renewal_time": "0001-01-01T00:00:00Z",
        "login_role": "example-dot-com",
        "namespace": "",
        "path": "auth/approle/login",
        "token_accessor": "LkFUFhSYEKaV8YTEtimPn3cL",
        "token_entity_id": "41e53bca-bb1b-4ca9-09a5-184de1f39ce2",
        "version": "1"
      },
      "entity_ids": [
        "hvs.G615l6Y7vFExM3XlxRn71scQ",
        "41e53bca-bb1b-4ca9-09a5-184de1f39ce2"
      ]
    },
    "event_type": "core/lease-revoke"
  },
  "datacontentype": "application/cloudevents",
  "time": "2023-09-20T11:08:55.187169-07:00"
}

[benashz]

One problem I see here is that leaseIDs are sensitive information: if you know the leaseID, you can revoke or renew it. It's not unusual for the /sys/leases/revoke endpoint to be granted in policies, and sys/leases/renew is in the default policy. Renewal could be used as part of an attack, e.g.: I don't have access to this crashed application's token, but I do have a valid token from elsewhere, and I want to make use of the dynamic db credential I stole from the app.

@ncabatoff That's really good to know. So are you saying we should never include the leaseID in logs, events, etc., since those sources may leak out of the producer?

[ncabatoff]

One problem I see here is that leaseIDs are sensitive information: if you know the leaseID, you can revoke or renew it. It's not unusual for the /sys/leases/revoke endpoint to be granted in policies, and sys/leases/renew is in the default policy. Renewal could be used as part of an attack, e.g.: I don't have access to this crashed application's token, but I do have a valid token from elsewhere, and I want to make use of the dynamic db credential I stole from the app.

@ncabatoff That's really good to know. So are you saying we should never include the leaseID in logs, events, etc., since those sources may leak out of the producer?

@bash Yes.

[swenson]

@ncabatoff and others, any other feedback on this, or other work I should do to get this ready for merging?