Expose eks cluster certificate authority data in status

[hanlins]

Description of your changes

Fixes #955

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

Added unit test for the new field introduced.

[hasheddan]

@hanlins the CA data is currently exposed in the connection secret that gets created for the cluster -- is that suitable for your use case?

[hanlins]

@hanlins the CA data is currently exposed in the connection secret that gets created for the cluster -- is that suitable for your use case?

Hi @hasheddan, thanks a lot! Btw, is there a way to figure out what's inside that secret without digging into code? Currently, the secret reference is in the cluster spec, and the contents in that secret are actually controlled by the implementation of the controllers, not part of the CRD API contract. I'm fine relying on this implicit contract, but is there a better way to document this and make it more explicit? For now I think user has to either really provision a Cluster object and check what's in that referenced secret, or go through the code as you pointed above to learn what's in that secret, it would be nice to make this information explicit since it's the interface to users. If there're some documents on this (or did I miss any existing docs?) that make this API clear to the users, if so then I'm ok to close this PR :)

[haarchri]

@hasheddan did we have in crossplane compositions an patch like fromConnectionSecretKey then it is easier to get informations from ConnectionSecretKey to other resources

[ONordander]

Having the clusterCA exposed in the status would solve my use-case of automatically adding the cluster to ArgoCD by using the provider-kubernetes.
So +1 for this

[muvaf]

Is certificate authority data sensitive? If so, we can't have it under status.

[janwillies]

This is basically the question in crossplane/crossplane#2772 (comment)

[chlunde]

I don't think it should be considered sensitive. It's the public key for validating the control plane certificate, but kubectl does omit it for brevity: https://github.com/kubernetes/client-go/blob/f6ce18ae578c8cca64d14ab9687824d9e1305a67/tools/clientcmd/api/helpers.go#L83-L112

[haarchri]

I am fine to merge the Open PR to add this ca in status

[hanlins]

Any further thoughts/concerns? Should we merge this change? @haarchri :)

[ONordander]

Any updates on this? Would be nice to have in the next release.

[haarchri]

@hanlins thanks for implementation
@chlunde thanks for add clarification for CAdata