fix(etcd): set correct permissions on certs generated on first etcd node

[mehrdadbn9]

What type of PR is this?

/kind bug

What this PR does / why we need it

On the first etcd node, make-ssl-etcd.sh generates the etcd certs and moves them into /etc/ssl/etcd as root:root with umask-based permissions (0600 for keys, 0644 for certs). Every other etcd node receives the certs through the slurp/copy path with the correct etcd:${etcd_cert_group} ownership and 0640 mode, so only the generating node is inconsistent.

This broke an etcd backup job running on the first control-plane node with a read-permission error (see issue for repro).

This PR adds one normalization task in roles/etcd/tasks/gen_certs_script.yml right after cert generation on the first etcd node. It sets the same owner/group and the same mode split the copy path already uses:

• 0644 for public certs (ca.pem, admin-.pem, member-.pem, node-*.pem)
• 0600 for private keys (*-key.pem)

The task reuses etcd_owner / etcd_cert_group so behavior stays consistent with the copy tasks, and it only runs when gen_certs is true (generation happened).

Which issue(s) this PR fixes

Fixes #13250

Special notes for your reviewer

• Delegation matches the generation task: delegate_to: "{{ groups['etcd'][0] }}" + run_once: true, so it runs exactly where the certs are generated.
• File names use {{ inventory_hostname }} because that is how the generator names certs (same pattern as the slurp/copy tasks above).
• Modes deliberately keep 0600 on keys (stricter than the copy path's 0640) to match upstream etcd PKI conventions; happy to align to 0640 if reviewers prefer exact parity with the copy path.

Does this PR introduce a user-facing change?

Fix etcd certificate permissions on the first etcd node: generated certs are now normalized to the same ownership (etcd:${etcd_cert_group}) and mode split (0644 certs / 0600 keys) as the certs copied to other etcd nodes.

[kubernetes-prow]

Hi @mehrdadbn9. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mehrdadbn9
Once this PR has been reviewed and has the lgtm label, please assign mzaian for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[yankay]

/ok-to-test

[Copilot]

🟡 Changes recommended

The new file: loop can create empty cert/key files when a listed path doesn’t exist (e.g., node certs on a dedicated etcd host), and the proposed modes don’t currently match the existing copy-path behavior, so the “normalization” may still be inconsistent.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR addresses inconsistent ownership/permissions of etcd certificates on the first etcd node (the node where make-ssl-etcd.sh generates certs), so that jobs reading the certs (e.g., backups) behave consistently across all etcd nodes.

Changes:

• Adds a post-generation normalization task in roles/etcd/tasks/gen_certs_script.yml to set owner/group/mode for certs generated on the first etcd node.

File summaries

File	Description
roles/etcd/tasks/gen_certs_script.yml	Adds a new task intended to normalize ownership/mode of generated etcd PKI artifacts on the first etcd node.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mehrdadbn9]

Root-caused the 2 CI failures (ubuntu24-ha-separate-etcd, ubuntu24-cilium-sep): the previous revision referenced node-{{ inventory_hostname }} certs on the first etcd node, but node-* certs are named after control-plane hosts (make-ssl-etcd.sh generates them from the HOSTS variable = gen_node_certs_True ∩ kube_control_plane). With etcd and control-plane on separate machines those files don't exist on the etcd node and the file task fails.

The pushed revision derives the file list from the same group expressions the generator uses: member/admin for every etcd host, node-* for gen_node_certs_True ∩ kube_control_plane hosts, plus ca.

Verified locally with ansible 2.16 against a separate-etcd topology (etcd1/etcd2 + cp1/cp2): certs land 0644, keys 0600, both tasks ok, and the absent-file case that broke CI is gone because the file list now matches exactly what the generator produces on that node.