It would help a lot to have a Why for each section. For example, why use a private topology? Why block access to the AWS Metadata API?
I'm not saying it's wrong to do those things, but it would help to prioritize changes if you can understand the severity of the security vulnerabilities you're exposed to.
This guide really has no audience. If you are responsible for a K8ts cluster you will need a depth of knowledge that requires knowing why. If you are using a hosted K8ts then you only need to know potential issues (why again). No one needs to know only what to do.
Yes please! It's one thing to know what you should do because you've been told to do so, but quite another to fully understand why you're doing something.
I'm not saying it's wrong to do those things, but it would help to prioritize changes if you can understand the severity of the security vulnerabilities you're exposed to.