terraform-aws-iam
terraform-aws-iam copied to clipboard
terraform-aws-modules
feat: Allow access to keypairs for Karpenter controller policy
When Karpenter provisioners are using a custom LaunchTemplate there is a chance that it includes a custom key-pair.
I'm not sure about this addition since Karpenter relies on the AmazonSSMManagedInstanceCore policy and therefore remote access is available via SSM
I'm not sure about this addition since Karpenter relies on the AmazonSSMManagedInstanceCore policy and therefore remote access is available via SSM
Since adding a Keypair is a feature of Launch templates why would someone limit this? We usually connect on our instances via SSH if we need to debug something! I mean the fact that there is remote connection through SSM Managed Instance is kind of irrelevant to the fact that one can use a custom keypair!
Understood - but this is not a recommended practice over using something like SSM where credentials are ephemeral and access can be controlled through policies.
I think if you want to add this permission, the route I would suggest today is to add it through a custom policy and attach it to the role using role_policy_arns.
Understood - but this is not a recommended practice over using something like SSM where credentials are ephemeral and access can be controlled through policies.
I think if you want to add this permission, the route I would suggest today is to add it through a custom policy and attach it to the role using
role_policy_arns.
Hello @bryantbiggs , thank you for your feedback!
This is what I am currently doing in order to work around it, but I am not sure why this might not be a feature that could be added. Even if it is not a recommended practice, I certainly believe there are a lot customers out there that will probably migrate from CA to Karpenter and may be using LTs with custom keypairs. 🤔
Identical issue here, was going to make the same PR. It may not be the default but I could suggest making it an optional flag? Arriving at the solution of attaching an additional policy takes some time to hunt down the real issue and come to that conclusion; this difficulty will be multiplied by the number of users migrating from CA to Karpenter using this module, so it might be worth making more explicit at least.
Identical issue here, was going to make the same PR. It may not be the default but I could suggest making it an optional flag? Arriving at the solution of attaching an additional policy takes some time to hunt down the real issue and come to that conclusion; this difficulty will be multiplied by the number of users migrating from CA to Karpenter using this module, so it might be worth making more explicit at least.
Indeed, this is my main reasoning as well, of course I am open to changing things to optional if needed, or adding a flag to create an additional policy attachment and not have it included by default!
This PR has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this PR will be closed in 10 days
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This PR has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this PR will be closed in 10 days
Even if it is not a recommended practice, I certainly believe there are a lot customers out there that will probably migrate from CA to Karpenter and may be using LTs with custom keypairs. 🤔
We are exactly in this category.
This PR has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this PR will be closed in 10 days
This PR has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this PR will be closed in 10 days
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.