<p>I would like to develop a playbook rule for addressing how to manage socket securing for Docker and Kubernetes from either the standpoint of Docker For Mac or MiniKube- after auto-updates to any of the pieces of the puzzle. Maybe we need to throw out there the LLVM or (VM in question if we say use Virtual Box <em>and</em> a particular Unix/Linux flavor. Then we may also need look at enforcing SELinux or AppArmor or Seccomp. I just want to see where this rabbit hole may end us up in today, 2019-09-25, as I just embarked on the Kubernetes quest with minishift, co, and micro-services architecture with RHEL (I may sway away from the OS image to Alpine or something someone may suggest as a suitable alternative). The goal here is to provide support to a team from a system administration point of view, potentially from the stance of calming some long lived traditional experience in the world concerns with real manageable solutions to infrastructure migrations for larger business.  </p>

<p>RHEL D0092 course work. Months of reading documentation with Docker and watching the past four updates on my development machine go by without a workable solution, knowing the inevitability was to get a Kubernetes cluster going after chewing on Kerrisk's bible for a while on the subject matter- Datagrams and Stream sockets and the like (and how people like to port it well for their individual use cases). I'm a novice system admin here, don't let me fool you. I just am not afraid to ride the big waves, that's all.</p>

<pre class="lang-sh prettyprint-override"><code>kubectl --namespace=kubedemo set image deployment/myvertex myvertex=burr/myvertx:v2
</code></pre>

<p>or </p>

<pre class="lang-py prettyprint-override"><code>import subprocess
import sys
import os

if len(sys.argv) &gt; 1:
    name = sys.argv[1]
else:
    # fd = input(the_path_passed_stdin)
    name = input("Update path/name for docker build:")

# test this with a "dryrun" first, you don't need a bunch of image clutter or control -c's
# No such file or directory trace means we need to call docker directly
proc = subprocess.run([f"error_test docker build -it {name} ."], encoding='utf-8', stdout=subprocess.PIPE)
</code></pre>

<p>Just a thought on automation of a playbook rule in some type of sequential fashion- in python if I can get suggestions, but bash is fine too.</p>

Rudy 
<p>Kubernetes works over an HTTP API and normal IP sockets, not a local domain socket. So there isn't really anything to lock down. DfM's control socket is already tightly locked down to the active GUI user because DfM runs inside a Mac app container (totally different use of the term "container"). Basically there isn't anything you need to do, it's already as safe as it's getting.</p>
