#77 Addressing backlog issue about registered AKS clusters

[martyav]

While going through backlog, I did a review of #77. Some, but not all, of the problems mentioned in the issue have been addressed. Rather than creating a PR for the entire issue, I'm going to pick through it to make sure that the problems are still relevant to the current state of the docs.

In #77 (comment) from the thread:

Please also look at https://rancher.com/docs/rancher/v2.6/en/cluster-provisioning/registered-clusters/#additional-features-for-registered-eks-and-gke-clusters where it does not mention AKS clusters (my understanding is that AKS clusters can be registered too):

Additional Features for Registered EKS and GKE Clusters
Registering an Amazon EKS cluster or GKE cluster allows Rancher to treat it as though it were created in Rancher.
Amazon EKS clusters and GKE clusters can now be registered in Rancher. For the most part, these registered clusters are treated the same way as clusters created in the Rancher UI, except for deletion.
When you delete an EKS cluster or GKE cluster that was created in Rancher, the cluster is destroyed. When you delete a cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher.
The capabilities for registered clusters are listed in the table on this page.

This was answered with #77 (comment):

https://rancher.com/docs/rancher/v2.6/en/cluster-provisioning/

Thanks for your contribution. AKS came along a little later and can be registered as well, as you noted.

[...] add "AKS" to the verbiage, tables, and sections wherein we only mention EKS and GKE cluster registration in the links provided. Thanks!

At the time, this related to Rancher v2.6, but the v2.6 page wasn't updated. v2.7 does mention AKS, but referred to it as "Azure AKS," which is inaccurate. The section also needed a style refresh.

I updated v2.6 and 2.7 to match. v2.5 was left alone as I'm not sure if it was intended to be updated in the original thread.

[martyav]

While going through the repo, I also found an instance of "EKS and GKE" verbiage left on CIS Scans. Since the intro to that page states,

The CIS scans can run on any Kubernetes cluster, including hosted Kubernetes providers such as EKS, AKS, and GKE

are we safe in updating the following to include AKS?

The EKS and GKE cluster scan profiles are based on CIS Benchmark versions that are specific to those types of clusters.

The rancher-cis-benchmark supports the CIS 1.6 Benchmark version.

• For RKE Kubernetes clusters, the RKE Permissive 1.6 profile is the default.
• EKS and GKE have their own CIS Benchmarks published by kube-bench. The corresponding test profiles are used by default for those clusters.
• For RKE2 Kubernetes clusters, the RKE2 Permissive 1.6 profile is the default.
• For cluster types other than RKE, RKE2, EKS and GKE, the Generic CIS 1.5 profile will be used by default.

I think this might be a question for @jiaqiluo.

[jiaqiluo]

@martyav, I do not have an answer because I am not the maintainer of the rancher-cis-benchmark app and have not tired/validated it on AKS cluster. I would like to bring @macedogm into the loop.

[macedogm]

@martyav / @jiaqiluo thanks for flagging this. The CIS chart is actually maintained by team/area3 (but is transitioning internally to another team). @mitulshah-suse and @rayandas can you help us with this update, please?

If we are going to update the CIS page, we also need to update the profiles to add the 1.20 and 1.23 versions to each distro.

[martyav]

@macedogm We have an open PR related to 1.20 and 1.23 (#209). We can address that issue there -- there's already been a lot of work put towards it, but it's been awaiting QA. Merging it will clear #34 from our backlog.

[btat]

The acronyms can be kept here and the acronym expansions should instead be moved earlier in the doc where they're first used.

[martyav]

@btat Just updated in 99e1ce2

[btat]

Suggested change

	To register a cluster in Rancher, you must define a `cluster-admin` role within that cluster. If you haven't defined the role already, run the following:
	To register a cluster in Rancher, you must have `cluster-admin` privileges within that cluster. If you don't, grant these privileges to your user by running the following:

[btat]

Suggested change

	Since, by default, Google Kubernetes Engine (GKE) doesn't define the `cluster-admin` role, you must run these commands on GKE clusters before you can register them. To learn more about role-based access control for GKE, please see [the official Google documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).
	Since, by default, Google Kubernetes Engine (GKE) doesn't grant the `cluster-admin` role, you must run these commands on GKE clusters before you can register them. To learn more about role-based access control for GKE, please see [the official Google documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).