-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Resource - azurerm_kubernetes_cluster_pod_identity
#11492
New Resource - azurerm_kubernetes_cluster_pod_identity
#11492
Conversation
ae52a40
to
acb9f89
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@njuCZ Thanks for this PR!
I've taken a look through and left some comments inline, but this is mostly looking good to me 👍
v := raw.(map[string]interface{}) | ||
name := v["name"].(string) | ||
namespace := v["namespace"].(string) | ||
if name == "" || namespace == "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this redundent given both properties are Required
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a comment above this line for this special handling, mentioning issue: hashicorp/terraform-plugin-sdk#588?
azurerm/internal/services/containers/kubernetes_cluster_pod_identity_resource_test.go
Outdated
Show resolved
Hide resolved
azurerm/internal/services/containers/kubernetes_cluster_pod_identity_resource_test.go
Show resolved
Hide resolved
azurerm/internal/services/containers/kubernetes_cluster_pod_identity_resource_test.go
Show resolved
Hide resolved
azurerm/internal/services/containers/kubernetes_cluster_pod_identity_resource_test.go
Show resolved
Hide resolved
acb9f89
to
1c9ef38
Compare
|
||
name := v["name"].(string) | ||
namespace := v["namespace"].(string) | ||
if name == "" || namespace == "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Persumably this only exists when your containing block has a Map
(see: hashicorp/terraform-plugin-sdk#588). Therefore, it is safe to remove these lines here.
v := raw.(map[string]interface{}) | ||
name := v["name"].(string) | ||
namespace := v["namespace"].(string) | ||
if name == "" || namespace == "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a comment above this line for this special handling, mentioning issue: hashicorp/terraform-plugin-sdk#588?
Thank you @njuCZ, LGTM 👍 |
azurerm_kubernetes_cluster_pod_identity
c74d205
to
3651acc
Compare
@magodo Any chance this can be added in the next version? |
+1, also waiting for this to be implemented. |
@njuCZ Could you please resolve the conflicts? |
3651acc
to
af4e35c
Compare
@magodo have rebased the code and fix all conflicts. |
@njuCZ Thank you! The tests are passing. |
)" This reverts commit db2d2a1.
@tombuildsstuff May I ask why it should not be a separate resource? and setting pod identity needs a role assignment first. |
@njuCZ firstly this feature (V1) is deprecated and will be removed by AKS in favour of V2 as detailed in the document above - so supporting this functionality for a couple of months to remove it is debatable. Secondly - since this is a User Assigned Identity that's a Managed Identity - the Managed Identity can have be created and have it's Role Assignment created prior to the cluster creation (or change) - this means (for example) during deletion, the Role Assignment will be removed once the Cluster has been deleted, not beforehand which could cause Pods to fail during runtime. Whilst arguably there's some minor usability benefits to splitting this out, the runtime trade-off and where only a single Pod Security Policy can be configured) - this makes more sense as a separate resource. As such I think the larger question at this point is should we support this functionality, given it's in Preview and is scheduled to be replaced by a new version the near future (which presumably has a different schema):
|
@tombuildsstuff Your point about this feature being preview and scheduled for deprecation in favor of v2 makes sense and is a decision that you and the other maintainers will need to make. But I'm having trouble following your other arguments around why this should not be a separate resource.
Isn't deletion of the identities after the cluster is deleted desirable? Why are we concerned about pods failing after the cluster has been deleted? There won't be any more pods at that point.
I'm having trouble parsing this at all... it sounds like you're arguing in favor of it being a separate resource. Regardless of whether this particular PR is accepted due to the v1 vs v2 issue, these design decisions will likely apply to the future v2 implementation as well. In any case, since this was reverted can we reopen #9885 please? |
This functionality has been released in v2.64.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
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 contributions. |
fix #9885
Based on work by @feliperoveran #10206
Support enabling ad-pod-identity, creating pod identities, and pod exceptions.
through doc https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity and discussion from thread #10206, and creating pod identity needs role assignment first, it's better to make a seperate resource
to test this resource, you must enable the feature
Microsoft.ContainerService/EnablePodIdentityPreview
in your subscription.you could do this through azure cli
poll until the status is
registered
bythen execute