Fix some nits in BootstrapConfig docs

Signed-off-by: Stefan Büringer buringerst@vmware.com

docs/book/src/developer/core/controllers/machine.md

@@ -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)

docs/book/src/developer/providers/contracts/bootstrap-config.md

@@ -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.
@@ -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,
@@ -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.
 
@@ -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
@@ -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">

docs/book/src/developer/providers/contracts/infra-machine.md

@@ -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.
 

docs/book/src/developer/providers/security-guidelines.md

@@ -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:
 
@@ -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.