Is your feature request related to a problem? Please describe.
The csp adapter is currently only installable on EKS clusters. This limitation is due to it's usage of iam roles for service accounts, which provides the csp adapter with the necessary permissions to to manage entitlements within license manager.
Describe the solution you'd like
There is documentation which indicates that IAM Roles for service accounts is supported for non-eks clusters (DIY K8s and EKS anywhere). We should augment our existing documentation to explain to customers how to utilize these systems to deploy the adapter on non-eks clusters.
Describe alternatives you've considered
There are other methods of AWS auth from kubernetes, including:
Hardcoded, user-provided, access key and secret key (probably in a k8s secret in the local cluster)
Third party credential providers (vault)
Each of these solutions has issues, but in short, the overall issues are:
Require changes to the adapter or the adapter's chart to support multiple types of auth for one csp
Violate security best practices (node role would allow more than just the adapter to have access to license manager, hardcoded credentials would be hard to manage over time)
Require tight coupling with third-party systems that we don't own
Additional context
The desired solution would also potentially allow us to publish automation (terraform/cloudformation) which would allow users to easily create this integration. However, this should be seen as a long-term goal rather than a short-term goal.
Is your feature request related to a problem? Please describe. The csp adapter is currently only installable on EKS clusters. This limitation is due to it's usage of iam roles for service accounts, which provides the csp adapter with the necessary permissions to to manage entitlements within license manager.
Describe the solution you'd like There is documentation which indicates that IAM Roles for service accounts is supported for non-eks clusters (DIY K8s and EKS anywhere). We should augment our existing documentation to explain to customers how to utilize these systems to deploy the adapter on non-eks clusters.
Describe alternatives you've considered There are other methods of AWS auth from kubernetes, including:
Each of these solutions has issues, but in short, the overall issues are:
Additional context The desired solution would also potentially allow us to publish automation (terraform/cloudformation) which would allow users to easily create this integration. However, this should be seen as a long-term goal rather than a short-term goal.