Enhance Kubernetes configuration by setting kubeconfig permissions

[redscholar]

What type of PR is this?

/kind bug

What this PR does / why we need it:

• Added tasks to set permissions for the kubeconfig file in both the renewal and join processes, ensuring proper access control.
• Introduced a function to retrieve the current local user, improving user context handling in the local connector.
• Updated the SSH connector to pass the SUDO_USER environment variable, enhancing command execution context.

These changes improve security and user management in Kubernetes operations.

Which issue(s) this PR fixes:

Fixes #

Special notes for reviewers:

Does this PR introduced a user-facing change?

none

Additional documentation, usage docs, etc.:

[kubesphere-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: redscholar

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [redscholar]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the security and user management aspects of Kubernetes operations. It introduces robust mechanisms for setting appropriate permissions on kubeconfig files during cluster setup and renewal, preventing unauthorized access. Furthermore, it refines how user context is handled within the system's connectors, ensuring that commands executed with sudo correctly reflect the initiating user.

Highlights

• Kubeconfig Permissions: Implemented tasks to correctly set file permissions for kubeconfig during Kubernetes certificate renewal and cluster joining processes, ensuring proper access control.
• Local User Retrieval: Introduced a new function getLocalUser in the local connector to dynamically determine the current local user, improving user context handling.
• SUDO_USER Environment Variable: Ensured the SUDO_USER environment variable is properly passed in both local and SSH connector command executions for enhanced command context.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gemini-code-assist]

Code Review

This pull request introduces changes to explicitly set the SUDO_USER environment variable for sudo commands executed via local and SSH connectors, and adds chown tasks in Kubernetes Ansible playbooks to manage kubeconfig file permissions. However, the local_connector.go implementation for setting SUDO_USER is problematic as command.SetEnv replaces the entire environment, potentially breaking sudo by removing essential variables like PATH. Furthermore, the chown commands in the Ansible playbooks contain a logical flaw where ~ expands to /root when run with sudo, causing both chown operations to target /root/.kube/config and thus making the intended user-specific permission change ineffective.

[gemini-code-assist]

command.SetEnv replaces the entire environment for the child process. This will likely cause the sudo command to fail because essential environment variables like PATH will be missing. You should append to the current environment instead of replacing it to ensure the command executes in a valid context.

Suggested change

	command.SetEnv([]string{"SUDO_USER=" + c.User})
	command.SetEnv(append(os.Environ(), "SUDO_USER="+c.User))

[gemini-code-assist]

The chown command for the user's kubeconfig is flawed. When the command is executed with sudo, the shell runs as root, causing ~ to expand to /root. As a result, both chown commands in this task operate on the same file, /root/.kube/config. The second command immediately overwrites the first, making the permission change for $SUDO_USER ineffective. You should use a more reliable method to get the user's home directory.

    if [ -n "$SUDO_USER" ] && [ "$SUDO_USER" != "root" ]; then
      USER_HOME=$(getent passwd "$SUDO_USER" | cut -d: -f6)
      if [ -n "$USER_HOME" ]; then
        chown "$SUDO_USER":root "$USER_HOME"/.kube/config
      fi
    fi
    chown root:root /root/.kube/config

[gemini-code-assist]

This command has a logical flaw. When executed with sudo, the shell runs as root, so ~ expands to /root. This means both chown commands target /root/.kube/config. The second command (chown root:root ...) nullifies the effect of the first one. To correctly set permissions for the user who invoked sudo, you need to determine their home directory explicitly rather than using ~.

    if [ -n "$SUDO_USER" ] && [ "$SUDO_USER" != "root" ]; then
      USER_HOME=$(getent passwd "$SUDO_USER" | cut -d: -f6)
      if [ -n "$USER_HOME" ]; then
        chown "$SUDO_USER":root "$USER_HOME"/.kube/config
      fi
    fi
    chown root:root /root/.kube/config