-
Notifications
You must be signed in to change notification settings - Fork 75
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
Fix issue 276: Double encoded KubernetesCluster connection secrets #407
Conversation
config/containerservice/config.go
Outdated
@@ -26,25 +25,6 @@ import ( | |||
// Configure configures kubernetes group | |||
func Configure(p *config.Provider) { | |||
p.AddResourceConfigurator("azurerm_kubernetes_cluster", func(r *config.Resource) { | |||
// Note(ezgidemirel): Following fields are not marked as "sensitive" in Terraform cli schema output. | |||
// We need to configure them explicitly to store in connectionDetails secret. | |||
r.TerraformResource.Schema["kube_admin_config"].Elem.(*schema.Resource). |
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.
Looks like the kube_admin_config[].client_certificate
has already set Sensitive to true but when you remove the configuration override here, a corresponding field gets generated in the status. I was not expecting this, i.e., I was thinking that the configuration override we have here was unnecessary.
Following fields are not marked as "sensitive" in Terraform cli schema output.
We will need to check further why we need this override. The comment here says that these are not marked as sensitive in the JSON schema. But in the native schema, this is already marked as sensitive. So, I believe for some reason, we are losing this important information by not consuming the native schema.
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.
@svscheg as I stated in the issue, I would suggest using AdditionalConnectionDetailsFn
configuration to end up with the exact connection secret we want, e.g. encoded only once.
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.
a1a01b2
to
aeb42ff
Compare
/test-examples="examples/containerservice/kubernetescluster.yaml" |
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.
@svscheg thanks!
It would be good to check the content of the connection secret after the resource is ready. Could you update the How this code has been tested section with the content of that secret (should be ok to share even sensitive given it is a test cluster to be deleted)?
I am also wondering if you could use that kubeconfig
to connect to the cluster with kubectl?
Hi @turkenh ! I added files with secret before the changes and after the changes. |
base64 -D <<< `paste-the-kubeconfig-here` > /tmp/k
export KUBECONFIG=/tmp/k
kubectl get nodes If the kubectl command works, then we're good. |
Hi @turkenh ! Is it correct or something is not ok? |
@turkenh maybe we have some ways to re-check attributes kubeconfig.clustercacertificate, kubeconfig.clientcertificate, kubeconfig.clientkey? |
@svscheg, looks like it is a valid kubeconfig but your cluster was not ready yet or there were some connectivity problems. Ideally, I would like to see a successful output with a list of nodes.
The above procedure would validate all together without checking them individually. |
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.
This looks good to me.
As I commented above, seeing a successful kubectl get nodes
with the generated config would be good before merge. But I am fine with approving as the code itself looks good and previous test @svscheg partially validated that generated kubeconfig is a valid one.
Tested manually and
|
Description of your changes
Fixes first part for issue #276
I have:
make reviewable test
to ensure this PR is ready for review.How has this code been tested
Manually
Uptest: https://github.com/upbound/provider-azure/actions/runs/5268824377
Secret before the changes:
before_fix_changes.txt
Secret after the changes:
after_changed.txt