From c247cda3e2860f7c5da8dae969ba0abd370d03ea Mon Sep 17 00:00:00 2001
From: CRC <6834943+christophercarney@users.noreply.github.com>
Date: Wed, 6 Nov 2019 20:42:43 -0500
Subject: [PATCH] Clarify init container use case for security (#17404)

---
 content/en/docs/concepts/workloads/pods/init-containers.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md
index 01f24f868e..ef4c5eeed9 100644
--- a/content/en/docs/concepts/workloads/pods/init-containers.md
+++ b/content/en/docs/concepts/workloads/pods/init-containers.md
@@ -62,7 +62,6 @@ have some advantages for start-up related code:
 * Init containers can contain utilities or custom code for setup that are not present in an app
   image. For example, there is no need to make an image `FROM` another image just to use a tool like
   `sed`, `awk`, `python`, or `dig` during setup.
-* Init containers can securely run utilities that would make an app container image less secure.
 * The application image builder and deployer roles can work independently without
   the need to jointly build a single app image.
 * Init containers can run with a different view of the filesystem than app containers in the
@@ -71,6 +70,9 @@ have some advantages for start-up related code:
 * Because init containers run to completion before any app containers start, init containers offer
   a mechanism to block or delay app container startup until a set of preconditions are met. Once
   preconditions are met, all of the app containers in a Pod can start in parallel.
+* Init containers can securely run utilities or custom code that would otherwise make an app
+  container image less secure. By keeping unnecessary tools separate you can limit the attack  
+  surface of your app container image. 
 
 
 ### Examples