Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

📖 Fix some nits in BootstrapConfig docs #11274

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/book/src/developer/core/controllers/machine.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ When a node appears with `Node.Spec.ProviderID` matching `Machine.Spec.ProviderI
transitions the associated machine into the `Provisioned` state. When the infrastructure ref is also
`Ready`, the machine controller marks the machine as `Running`.

The following schema goes trough machine phases and interactions with InfraMachine and BootstrapConfig
The following schema goes through machine phases and interactions with InfraMachine and BootstrapConfig
happening at each step.

![](../../../images/machine-phases.png)
12 changes: 6 additions & 6 deletions docs/book/src/developer/providers/contracts/bootstrap-config.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# Contract rules for BootstrapConfig

Bootstrap providers SHOULD implement an BootstrapConfig resource.
Bootstrap providers SHOULD implement a BootstrapConfig resource.

The goal of an BootstrapConfig resource is to generates bootstrap data that is used to bootstrap a Kubernetes node.
The goal of a BootstrapConfig resource is to generates bootstrap data that is used to bootstrap a Kubernetes node.
These may be e.g. [cloud-init] scripts.

The BootstrapConfig resource will be referenced by one of the Cluster API core resources, Machine.
Expand All @@ -11,7 +11,7 @@ The [Machine's controller](../../core/controllers/machine.md) will be responsibl
and the interaction between the Machine's controller and the BootstrapConfig resource is based on the contract
rules defined in this page.

Once contract rules are satisfied by an BootstrapConfig implementation, other implementation details
Once contract rules are satisfied by a BootstrapConfig implementation, other implementation details
could be addressed according to the specific needs (Cluster API is not prescriptive).

Nevertheless, it is always recommended to take a look at Cluster API controllers,
Expand All @@ -29,7 +29,7 @@ When developing a provider, you MUST consider any Cluster API behaviour that is
as a Cluster API internal implementation detail, and internal implementation details can change at any time.

Accordingly, in order to not expose users to the risk that your provider breaks when the Cluster API internal behavior
changes, you MUST NOT rely on any Cluster API internal behaviour when implementing an BootstrapConfig resource.
changes, you MUST NOT rely on any Cluster API internal behaviour when implementing a BootstrapConfig resource.

Instead, whenever you need something more from the Cluster API contract, you MUST engage the community.

Expand Down Expand Up @@ -215,7 +215,7 @@ the Machine controller will surface this info in Machine's `spec.boostrap.dataSe

### BootstrapConfig: initialization completed

Each BootstrapConfig MUST report when the the bootstrap data secret is fully provisioned (initialization) by setting
Each BootstrapConfig MUST report when the bootstrap data secret is fully provisioned (initialization) by setting
`status.ready` in the BootstrapConfig resource.

```go
Expand All @@ -229,7 +229,7 @@ type FooConfigStatus struct {
}
```

Once `status.ready` the Machine "core" controller will bubbles up this info in Machine's `status.bootstrapConfigReady`;
Once `status.ready` the Machine "core" controller will bubble up this info in Machine's `status.bootstrapConfigReady`;
Also BootstrapConfig's `status.dataSecretName` will be surfaced on Machine's corresponding fields at the same time.

<aside class="note warning">
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -293,7 +293,7 @@ type FooMachineStatus struct {
}
```

Once `status.ready` the Machine "core" controller will bubbles up this info in Machine's `status.infrastructureReady`;
Once `status.ready` the Machine "core" controller will bubble up this info in Machine's `status.infrastructureReady`;
Also InfraMachine's `spec.providerID` and `status.addresses` will be surfaced on Machine's
corresponding fields at the same time.

Expand Down
4 changes: 2 additions & 2 deletions docs/book/src/developer/providers/security-guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ There are several critical areas that any infrastructure provider implementer mu
- **Ensuring secure access to VMs** for troubleshooting, with proper authentication methods.
- **Controlling manual operations** performed on cloud infrastructure targeted by the provider.
- **Housekeeping** of the cloud infrastructure, ensuring timely cleanup and garbage collection of unused resources.
- **Securing Machine's bootstrap data** ensuring protection oversensitive data that might be included in it.
- **Securing Machine's bootstrap data** ensuring protection of oversensitive data that might be included in it.

The following list outlines high-level security recommendations. It is a community-maintained resource, and everyone’s contributions are essential to continuously improve and adapt these best practices. Each provider implementer is responsible for translating these recommendations to fit the context of their specific cloud provider:

Expand All @@ -26,4 +26,4 @@ The following list outlines high-level security recommendations. It is a communi
Any cloud resource not linked to a cluster after a fixed configurable period, created by cloud credentials, should be automatically deleted or marked for garbage collection to avoid resource sprawl.

6. **Securing Machine's bootstrap data**:
Bootstrap data are usually stored in machine's metadata, and they might contain sensitive data, like e.g. Cluster secrets, user credentials, ssh certificates etc. It is important to ensure protections of those metadata, or if not possible, to clean up them immediately after machine bootstrap.
Bootstrap data are usually stored in machine's metadata, and they might contain sensitive data, like e.g. Cluster secrets, user credentials, ssh certificates etc. It is important to ensure protection of this metadata, or if not possible, to clean it up immediately after machine bootstrap.
Loading