Open raymondbutcher opened 6 years ago
This could be helpful although it would require some complex logic in a lambda rather than in ssha.
A few moments to think about:
Agreed.
It would make sense for ssha to invoke a Lambda function instead of sending an SSM command. So rather than having:
ssm {
document {
name = "add-ssh-key"
}
parameters {
username = ["${ssh.username}"]
key = ["$(cat '${ssh.identityfile_public}')"]
}
}
It would be something like:
lambda {
function {
name = "ssha-connection"
}
payload {
username = ["${ssh.username}"]
key = ["$(cat '${ssh.identityfile_public}')"]
}
}
The function would need to store connection details (username, instance id, client ip?) as tags on the security group, or in DynamoDB, or S3. We'd have to look more closely to see what suits. Also need to make sure that it doesn't cause issues with Terraform (dynamic security groups/rules).
I think for cleanup it could make sense to have another Lambda call, scheduled hourly, that checks the stored connection details and runs SSM to check if the user is still connected. If there is no connection, it is then safe to remove the security group rule and also the relevant public key from the instance, and the stored connection details.
Closing this. 5a6bad06497ac9f36fc420ebffac82431a47db79 adds Session Manager which avoids all of this mess.
Actually, this could still be useful for situations like running scp and shuttle.
Consider managing security groups to open up ports on demand.
Could be implemented via a ssh pre-hook lambda call?