Limit permissions of `gardener-node-agent` instances to required objects

[oliver-goetz]

How to categorize this issue?

/area security
/kind enhancement

What would you like to be added:
At the moment gardener-node-agent on every node share their service account (gardener-node-agent) and so also the same permissions.
This means that gardener-node-agents have to many permissions, because they could update Nodes and Leases which belong to different GNAs and they can read OperatingSystemConfig secrets of all worker groups.
The permissions could be reduced way without the necessity to update the core functionality of GNA.

🎯 Goals

• Each GNA has its own user
• Reduce permissions of GNA instances
  • GNA can update its own Node only
  • GNA has access to its own Lease only
  • GNA has access to the OSC secret of its own worker group only
• The feature should be switched on and off without the necessity to role the shoot nodes.

Implementation:

Usernames for GNA
Each instance of gardener-node-agent is using the name of its machine as username.
It cannot use the name of the node, because it is created by kubelet which is deployed by GNA.
It should not use the hostname, because we encountered cases where the hostname changed while GNA was running.
At the moment GNA does not know the name of its machine yet. That's why this feature needs an adapted machine-controller-manager and all provider specific implementations.

node-agent-authorizer webhook
For more granular permissions we cannot rely on the RBAC based authorization only, but could use a Webhook based approach similar to the the SeedAuthorizer we already implemented. The implementation of this NodeAgentAuthorizer could be simpler as there is no need for a dependency graph in this use case.
The webhook is implemented in gardener-resource-manager because it already serves multiple webhooks for shoots.

Certificate based authentication
Certificates and Certificate Signing Requests (CSR) are used to authenticate each GNA individually at the shoot kube-apiserver. The same concept is already used by gardenlet to authenticate at garden-apiserver.

GNA creates CSRs which are automatically approved under these conditions.

• a machine with the name of the GNA user must exist
• when a bootstrap token is used: there must not be a node for this machine
• when a GNA certificate is used: the requesting user and the common name of the certificate must be equal, so GNA is only allowed to renew its on certificate.

There is already a controller in GRM which approves CSRs for kubelet server certificates. This could be adapted for this use-case.

Tasks:

• Add machine-name to user data and as a node label in MCM: Introduce a feature to propagate the machine name to user data and as label to the node machine-controller-manager#919
• Update provider specific MCMs:
  • gardener/machine-controller-manager-alicloud: Update pipeline integratio tests to now run tests on a control cluster machine-controller-manager-provider-alicloud#86
  • gardener/machine-controller-manager-aws: [ci:component:github.com/gardener/machine-controller-manager:v0.53.0->v0.54.0] machine-controller-manager-provider-aws#175
  • gardener/machine-controller-manager-azure: [ci:component:github.com/gardener/machine-controller-manager:v0.53.1->v0.54.0] machine-controller-manager-provider-azure#166
  • gardener/machine-controller-manager-gcp: [ci:component:github.com/gardener/machine-controller-manager:v0.53.1->v0.54.0] machine-controller-manager-provider-gcp#129
  • gardener/machine-controller-manager-openstack: update mcm dependency machine-controller-manager-provider-openstack#181
  • ironcore-dev/machine-controller-manager-provider-ironcore: Bump MCM to v0.55.1 ironcore-dev/machine-controller-manager-provider-ironcore#442
  • ironcore-dev/machine-controller-manager-provider-metal: Bump github.com/gardener/machine-controller-manager from 0.53.1 to 0.54.0 ironcore-dev/machine-controller-manager-provider-ironcore-metal#20
  • metal-stack/machine-controller-manager-provider-metal: Revendor MCM v0.54.0. metal-stack/machine-controller-manager-provider-metal#38
• Introduce node-agent-authorizer webhook in gardener-resource-mananger: [node-agent-authorizer] Introduce node-agent-authorizer webhook in gardener-resource-manager  #10535
  • Introduce integration test for node-agent-authorizer webhook #10703
• Adapt CSRApprover of gardener-resource-manager to approve CSRs created by gardener-node-agent: [node-agent-authorizer] auto-approve gardener-node-agent CSRs in gardener-resource-manager #10549
• Implement webhook based authorization in gardener-node-agent: [node-agent-authorizer] Introduce webhook based authorization to gardener-node-agent #10781
• Promote NodeAgentAuthorizer feature gate to beta: Promote NodeAgentAuthorizer feature gate to beta #11757
• Graduate NodeAgentAuthorizer feature gate to GA: Graduate NodeAgentAuthorizer feature gate to GA #12405
• Remove access token based authorization and drop NodeAgentAuthorizer feature gate after gardener/gardener@v1.123 was released: Remove NodeAgentAuthorizer feature gate #12576

[oliver-goetz]

/assign

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Mark this issue as rotten with /lifecycle rotten
• Close this issue with /close

/lifecycle stale

[oliver-goetz]

/remove-lifecycle stale
/lifecycle active