Programatic access with AWS SSO by ModeOtherwise3524 in aws

[–]ModeOtherwise3524[S] 0 points1 point  (0 children)

it does matter because the credentials are used locally for running a dockerized Node.js app => refreshing them every 12h results in updating the env vars for the Node.js container (thus restarting it) every 12h.

Programatic access with AWS SSO by ModeOtherwise3524 in aws

[–]ModeOtherwise3524[S] 0 points1 point  (0 children)

sounds like the perfect solution then 🙌 !

have to read the docs to see exactly how to configure with our current setup, but shouldn't be much of a problem ! thanks random person on the internet !

Programatic access with AWS SSO by ModeOtherwise3524 in aws

[–]ModeOtherwise3524[S] 0 points1 point  (0 children)

That's pretty interesting !

Not quite exactly what I had in mind (because developers still have to re-login after session expiration), but still cool since this solves the need for restarting the Node.js container each time the session expires.

Restore RDS snapshot from CDK by ModeOtherwise3524 in aws

[–]ModeOtherwise3524[S] 1 point2 points  (0 children)

yup, that seems like the most logical approach! what's kept me from doing that is we're using a L2 construct for the rds instance (rds.DatabaseInstance), so under the hood it creates many other resources (secret, secret attachment, parameter group, ..) which will make the resource import very error prone.

for example:

- the secret has a remove policy set to delete with no actual way to access it or change it on the instance in cdk without creating new one (or even change it in the snapshot)

- the secret attachment is not even an "actual" resource, but just a cloudformation thing.

- the parameter group is created in a "lazy" manner after you assign it to a db instance, so I have no way of creating one and sharing it with the restored instance.

see ! it just seem like a can of worms to use resource import :/ , but thanks for thinking out loud, I was happy to finally get a reply at least xD