Generate a kubeconfig that can be used from remote machines #48
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The certificates that are generated for the kubeconfig file are only valid for for localhost (127.0.0.1) and cannot be downloaded and used from a remote machine. This PR adds two things to address this problem:
{{ ansible_ssh_host }}to thetls-sansection of therke_config.j2template so that the certificates generated are also valid for the instance's public IP address, and/etc/rancher/rke2/rke2.yaml) and saves it locally so it can be used to manage the cluster withkubectlandhelmcommands.Issues
The
kubeconfigfile is downloaded to a directory namedoutputsin the current directory on localhost. However, no checks are performed to ensure the directory exists and no attempt is made to create the directory if it is missing. Since creating the output directory needs to be performed onlocalhostit can't be added to therkerole and would have to be part of the main playbook. Otherwise the human operator needs to ensure the directory exists before running the playbook. One simple alternative would be to have theoutputsdirectory as part of the GitHub repository so it would be created for the user when they checkout the playbook(s).This solution may be slightly less secure as now access is permitted to the cluster where none was allowed before. However, this is true for SSH keys and other certificates that allow direct access to the underlying instances. While the cluster can typically be managed through the Rancher web interface this can be problematic when it is Rancher itself that is having problems or the web interface is too slow and clunky (think satellite internet from northern Canada say...)