Skip to content
Karpenter has emerged as the most advanced node scheduling technology for EKS currently available. And the Karpenter team has been hard at work making this open-source Kubernetes autoscaler even better.
The progression from its early alpha version (alphav5) to the more mature beta version (betav1) has brought significant improvements, particularly in aligning Karpenter’s operations with Identity and Access Management (IAM) and security best practices.
Previously, the alphav5 version employed a broad set of permissions, which simplified early development stages but introduced potential risks by over-provisioning access.
Transitioning to betav1, Karpenter has adopted a more granular and transparent approach to IAM permissions. With more fine-grained permissions, Karpenter can specifically request only the permissions needed to manage the lifecycle of EC2 instances it controls.
This enhances the ability to comply with security policies that enforce least privilege access. It also becomes easier to audit the actions that Karpenter can perform, aligning with security best practices and regulatory requirements. Now, users see exactly what actions Karpenter is authorized to perform for enhanced clarity and visibility.
| alphav5 | betav1 | |
| Permissions scope | Broad permissions that allow actions like ec2:*, which could potentially give access to all EC2-related operations across all instances. | Specific permissions that limit actions to only what is necessary. For example, instead of ec2:*, use ec2:RunInstances and ec2:TerminateInstances on specific ARNs. This ensures that Karpenter can only perform actions that are absolutely required for its functionality. |
| Condition application | Permissions without conditions, which could allow actions under any circumstances. | Adding conditions to policies to control when certain actions are permitted. For instance, allowing the ec2:CreateTags action only when the tag creation is part of the RunInstances operation. This condition ensures that tags can only be modified during instance creation, reducing the risk of inappropriate tag manipulation after instance provisioning. |
| Tagging | Inconsistent or broad tagging that may not fully support security, compliance, and cost management practices. | Implementing a standardized tagging strategy that includes tags for ownership, confidentiality level, environment (prod, dev, test), and compliance tracking. This helps in managing access control, auditing, and budgeting more effectively. |
In addition to the obvious security implications of more restrictive IAM permissions in the beta model, there’s a stronger emphasis on adhering to security best practices in general. This includes better audit trails, compliance with AWS security recommendations, and alignment with industry-standard security frameworks.
Let’s take a look at an example configuration to illustrate.
Example IAM policy: Karpenter alphav5 betav1
Let’s look at an example from an early version alphav5, with more generalized (simpler but less secure) Karpenter IAM policy.
Alphav5 IAM Policy Example
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": "*"
}
]
}
Now, let’s compare with an example from betav1, with more granular IAM policies adhering to the principle of least privilege.
Betav1 IAM Policy Example:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:TerminateInstances"
],
"Resource": [
"arn:aws:ec2:region:account-id:instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:region:account-id:volume/*",
"arn:aws:ec2:region:account-id:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:CreateAction": "RunInstances"
}
}
}
]
}
Note these key differences:
- Action Specificity: In betav1, the actions are very specific (ec2:RunInstances, ec2:TerminateInstances, ec2:CreateTags), compared to the broader ec2:* in alphav5.
- Resource Specificity: betav1 explicitly defines the resources (arn:aws:ec2:region:account-id:instance/*), enhancing security by limiting the scope of actions to specific instances.
- Condition Application: betav1 includes conditions (StringEquals) to ensure that some actions, like tagging, are only allowed under specific circumstances (e.g., during instance creation).
The Ultimate Guide to Karpenter
Wrapping up, the shift from alphav5 to betav1 in Karpenter’s API reflects a broader implementation of best practices in cloud security, focusing on minimizing risks and ensuring operation within a tightly controlled permissions framework. For organizations using Karpenter, it’s essential to update IAM roles and policies to align with these changes, ensuring that permissions are adequately scoped and adhere to the principle of least privilege.
Karpenter + nOps is even better
Here at nOps, we’re big fans of Karpenter. However, Karpenter doesn’t do everything. There are still limitations, especially if you’re trying to save with cost-effective Spot instances and optimize your Reserved Instance and Savings Plan commitments.
nOps Compute Copilot built on Karpenter is designed to make it simple for users to maintain stability and optimize resources efficiently. nOps helps engineering teams to more easily and effectively leverage the power of Karpenter and Spot to get lower costs and higher performance.
nOps adds the following capabilities to Karpenter — for more detail, check out the full breakdown of how Karpenter and nOps are better together.
At nOps, our mission is to make it easy for engineers to cost-optimize, so they can focus on building and innovating.
nOps was recently ranked #1 in G2’s cloud cost management category. Book a demo to find out how to save in just 10 minutes.
