feat: support native SSM expiration policies for runner token parameters - #5265
Conversation
|
Nice idea. Just a small note, I am working ro refactor the module to make easier to maintain and add new features. @Brend-Smits @npalm @guicaulada what do you think? |
|
@jvrplmlmn would mind rebasing and fixing conflicts on this one :) |
1dd5618 to
c99bf0a
Compare
1b78804 to
3ecca00
Compare
527aabc to
b0f983a
Compare
54cbd09 to
ac36954
Compare
|
@guicaulada Here I would like a second opinion. How about add support for this feature in global level(v2) too. So can be configure in global level and allow override per runner entry. Also @guicaulada the last commit not signed |
|
Weird.. why is the docs commit not signed? I thought we had fixed that already. EDIT: Apparently we didn't fix it for forks. |
Registration tokens and JIT configs written to SSM are orphaned when an instance fails to boot or is terminated before registering. The only cleanup today is the scheduled SSM housekeeper lambda, which cannot delete parameters younger than a day, so orphaned parameters (billed hourly when on the Advanced tier) can live for up to ~2 days. The new opt-in `ssm_token_ttl_seconds` attaches a native SSM Expiration policy to the token / JIT config parameters so SSM deletes leftovers itself once the TTL passes. Parameter policies require the Advanced tier, which incurs additional cost per parameter, hence disabled by default. Expiration is enforced asynchronously by SSM and is a cleanup mechanism rather than a security boundary; the housekeeper lambda remains as a backstop.
3ca164f to
52a0ad5
Compare
edersonbrilhante
left a comment
edersonbrilhante
left a comment
There was a problem hiding this comment.
Let's just create an issue to add support in v2 as well
3 participants
Description
Registration tokens and JIT configs written to SSM are orphaned when an instance fails to boot or is terminated before registering. The only cleanup today is the scheduled SSM housekeeper lambda, which cannot delete parameters younger than a day, so orphaned parameters (billed hourly when on the Advanced tier) can live for up to ~2 days.
The new opt-in
ssm_token_ttl_secondsattaches a native SSM Expiration policy to the token / JIT config parameters so SSM deletes leftovers itself once the TTL passes. Parameter policies require the Advanced tier, which incurs additional cost per parameter, hence disabled by default. Expiration is enforced asynchronously by SSM and is a cleanup mechanism rather than a security boundary; the housekeeper lambda remains as a backstop.Test Plan
Related Issues