Merge pull request aws#7 from urbanadventurer/master

Fix typos in Pods

content/security/docs/pods.md

@@ -213,14 +213,14 @@ When you specify _requests_ for CPU or memory, you’re essentially designating
 
 _Limits_ are the maximum amount of CPU and memory resources that a container is allowed to consume and directly corresponds to the `memory.limit_in_bytes` value of the cgroup created for the container.  A container that exceeds the memory limit will be OOM killed. If a container exceeds its CPU limit, it will be throttled. 
 
-Kubernetes uses 3 Quality of Service (QoS) classes to prioritize the workloads running on a node.  These include: guaranteed, burstable, and best effort.  If limits and requests are not set, the pod is configured as burstable (lowest priority).  Burstable pods are the first to get killed when there is insufficient memory.  If limits are set on _all_ containers within the pod, or if the requests and limits are set to the same values, the pod is configured as guaranteed (higheest priority).  Guaranteed pods will not be killed unless they exceed their configured memory limits. If the limits and requests are configured with different values, or 1 container within the pod sets limits and the other don’t or have limits set for different resources, the pods are configured as burstable (medium priority). These pods have some resource guarantees, but can be killed once they exceed their requested memory. Be aware that requests doesn’t actually affect the `memory_limit_in_bytes` value of the cgroup; the cgroup limit is set to the amount of memory available on the host. Nevertheless, setting the requests value too low could cause the pod to be targeted for termination by the kubelet if the node undergoes memory pressure. 
+Kubernetes uses three Quality of Service (QoS) classes to prioritize the workloads running on a node.  These include: guaranteed, burstable, and best effort.  If limits and requests are not set, the pod is configured as burstable (lowest priority).  Burstable pods are the first to get killed when there is insufficient memory.  If limits are set on _all_ containers within the pod, or if the requests and limits are set to the same values, the pod is configured as guaranteed (highest priority).  Guaranteed pods will not be killed unless they exceed their configured memory limits. If the limits and requests are configured with different values, or one container within the pod sets limits and the others don’t or have limits set for different resources, the pods are configured as burstable (medium priority). These pods have some resource guarantees, but can be killed once they exceed their requested memory. Be aware that requests doesn’t actually affect the `memory_limit_in_bytes` value of the cgroup; the cgroup limit is set to the amount of memory available on the host. Nevertheless, setting the requests value too low could cause the pod to be targeted for termination by the kubelet if the node undergoes memory pressure. 
 
-For additional information about resource QoS, please refer to the [Kubernetes documentation](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md)
+For additional information about resource QoS, please refer to the [Kubernetes documentation](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md).
 
 You can force the use of requests and limits by setting a [resource quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/) on a namespace or by creating a [limit range](https://kubernetes.io/docs/concepts/policy/limit-range/).  A resource quota allows you to specify the total amount of resources, e.g. CPU and RAM, allocated to a namespace.  When it’s applied to a namespace, it forces you to specify requests and limits for all containers deployed into that namespace. By contrast, limit ranges give you more granular control of the allocation of resources. With limit ranges you can min/max for CPU and memory resources per pod or per container within a namespace.  You can also use them to set default request/limit values if none are provided.
 
 ### Do not allow privileged escalation
-Privileged escalation allows a process to change the security context under which its running.  Sudo is a good example of this as are binaries with the SUID or SGID bit.  Privileged escalation is basically a way for users to execute a file with the permissions of another user or group.  You can prevent a container from privileged escalation by implementing a pod security policy that sets `allowPriviledgedEscalation` to `false` or by setting `securityContext.allowPrivilegedEscalation` in the `podSpec`.  
+Privileged escalation allows a process to change the security context under which its running.  Sudo is a good example of this as are binaries with the SUID or SGID bit.  Privileged escalation is basically a way for users to execute a file with the permissions of another user or group.  You can prevent a container from using privileged escalation by implementing a pod security policy that sets `allowPriviledgedEscalation` to `false` or by setting `securityContext.allowPrivilegedEscalation` in the `podSpec`.  
 
 ## Tools
 + [kube-psp-advisor](https://github.com/sysdiglabs/kube-psp-advisor) is a tool that makes it easier to create K8s Pod Security Policies (PSPs) from either a live K8s environment or from a single .yaml file containing a pod specification (Deployment, DaemonSet, Pod, etc).