Clean up expired bindings

[lnrdll]

While it might seem like a long shot, this issue primarily stems from the API and not this tool. Nevertheless, it's valuable to engage in a discussion regarding this matter and explore potential solutions.

When a temporary IAM binding is established, it appears in GCP's IAM view, complete with the condition name in the 'Conditions' column. The underlying 'problem' arises when these temporary bindings expire; they persist in the IAM view, potentially causing the list to grow significantly. Here's an example of an expired binding that remains visible in the IAM list:

I recall from a different issue thread that the intentional absence of a database was a deliberate design choice, driven by security considerations. A database would simplify the cleanup process. However, even though this issue is primarily related to the API and not the JIT tool, is there a way to address it within the application itself?

• Could the application, for instance, store a local file to keep track of projects requiring cleanup?
• Or could it publish project IDs to a Pub/Sub, allowing a background job to check for expired bindings?
• Another possibility is for the application to retain this information in memory.

[jpassing]

You're right that expired IAM bindings cause some clutter. FWIW, the application does purge expired bindings if a user requests the same role again -- so there's a limit to how many of these expired role bindings you can possibly accumulate in an IAM policy.

Or could it publish project IDs to a Pub/Sub, allowing a background job to check for expired bindings?

There was a PR attempting to do just that, but I'd have to follow up what the status is.

[jpassing]

There #97, but I'd have to follow up what the status is.

#154 will add Pub/Sub integration

[eeeeethan2333]

There #97, but I'd have to follow up what the status is.

#154 will add Pub/Sub integration

And after this pub/sub integration, I'm planning to provide pubsub consumer example to clean up the roles.