Security Self Assessment: [STRIDE-INFODISCLOSE-3] RFE: Improve certificate management in Cluster API

[fabriziopandini]

User Story

As a user/operator I would like to have control on how certificates are created
As a user/operator I would like to have visibility on certificate expiration date
As a user/operator I would like CAPI to support me in certificate lifecycle management
As a user/operator I would like to have the option to rely on external tools for certificate management

Detailed Description

As of today Cluster API provide a minimal support for certificate management, mostly util for management of secrets with certificate authorities, while over time the responsibility of creating certificates has been delegated to control plane providers.

While this approach worked well, some shortcomings are starting to surface, mostly boiling up to the fact that there is no top level certificate management primitives in our API, and this makes it difficult and fragmented the answer to:

• how can I customise certificate at provisioning time
• how can I monitor state of my certificates (expiration date)
• how can CAPI support me in certificate lifecycle management tasks, like certificate renewal or CA rotation

Last but not least, CAPI leaks of a clean interface for integrating with external tools for certificate management, like e.g Hashicorp Vault.

This issue is about starting an effort for rethinking this area, and providing a clean solution for addressing above concerns starting from the two issues that mostly concern users, that are better support for certificate renewal and CA rotation tasks

/kind feature
/kind proposal

@randomvariable to add more from a provider PoV

[vincepri]

/milestone v1.1

[vincepri]

/priority important-soon

[timothysc]

I agree with the sentiment, but I also think simple changes to kubeadm defaults would go a long way. cc @neolit123

[neolit123]

My take is that the default of 1 year is sane WRT keys sizes, RSA recommendations and k8s release cadence. Higher level tools have multiple options. - preping certs that are longer lived by signing kubeadm generated CSRs for multiple years. - having a controller that rotates certs and restarts nodes / components programmatically in the right sequence.

[randomvariable]

/area kcp

[k8s-ci-robot]

@randomvariable: The label(s) area/kcp cannot be applied, because the repository doesn't have them.

In response to this:

/area kcp

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/test-infra repository.

[randomvariable]

/area ?

[k8s-ci-robot]

@randomvariable: The label(s) area/? cannot be applied, because the repository doesn't have them.

In response to this:

/area ?

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/test-infra repository.

[randomvariable]

/area control-plane

[randomvariable]

@PushkarJ it would be good to get feedback from security folk.

[PushkarJ]

+1 Agree that it would be fantastic to get this as a built-in feature in CAPI. CA hierarchy and CAPI cluster hierarchy also lends itself several benefits of simplicity in how we could manage the root of trust.

However, it might be helpful to understand what problem we are trying to solve (which might be well-known but is worth re-iterating in detail) by sharing the current state and its drawbacks.

Is this were Cluster API Enhancement Proposal would come into picture that elaborates more on motivations, current state, its drawbacks and future state?

[randomvariable]

@randomvariable to add more from a provider PoV

I don't think there's anything more to add from a provider specific PoV. At least if we consider the possibility of leveraging cert-manager for generation, then we can defer provider specific implementations to it.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sbueringer]

/remove-lifecycle stale
/assign

[vincepri]

/lifecycle frozen

[PushkarJ]

Security Self Assessment: [STRIDE-INFODISCLOSE-3] RFE: Improve certificate management in Cluster API

[PushkarJ]

/retitle Security Self Assessment: [STRIDE-INFODISCLOSE-3] RFE: Improve certificate management in Cluster API
/area security
/sig security

[sbueringer]

I've created a separate issue to track machine certificate renewal specifically: #6529

[sbueringer]

/unassign

[fabriziopandini]

/triage accepted
@PushkarJ we are implementing automatic certificate renewal as described in #7268. is this enough to close this issue?

[PushkarJ]

@fabriziopandini the linked PR does look promising. We can close this with the usual caveat that if somebody feels like there is something left in the scope that is not covered in the new feature docs, we should reopen the issue.

[fabriziopandini]

Thanks @PushkarJ !
/close

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

Thanks @PushkarJ !
/close

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/test-infra repository.