<p dir="auto">When using native networking in in AWS (i.e. with options <code class="notranslate">cloud-provider=aws</code>, <code class="notranslate">cluster-name=&lt;cluster_name&gt;</code>, <code class="notranslate">allocate-node-cidrs=true</code>, <code class="notranslate">cluster-cidr=&lt;pod_network&gt;</code>, <code class="notranslate">configure-cbr0=true</code>, <code class="notranslate">bridge=cbr0</code>, <code class="notranslate">iptables=false</code>, and <code class="notranslate">ip-msq=false</code> as appropriate to <code class="notranslate">kube-apiserve</code>r, <code class="notranslate">kube-controller-manager</code>, <code class="notranslate">kubelet</code>, and <code class="notranslate">docker</code>), everything works except that Pods, including kube-dns, can't make DNS queries to the Amazon provided DNS server in the subnet.  That means Pods can't resolve external hostnames.</p>
<p dir="auto">It appears that the Amazon provided DNS server won't respond to queries with an address other than one within the subnet.  The solution to the problem is to masquerade traffic from the Pod network to the Amazon provided DNS server in the subnet.</p>
<p dir="auto"><code class="notranslate">sudo  iptables --table nat -A POSTROUTING -s &lt;pod_cidr&gt; -d &lt;dns_ip&gt;/32 -j MASQUERADE</code></p>
<p dir="auto">Arguably this should be done by <code class="notranslate">kubelet</code>when it is passed the <code class="notranslate">configure-cbr0</code> option alongside the <code class="notranslate">cloud-provider=aws</code> option.</p>
<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.): no</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.): s3, bucket, permissions</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one): BUG REPORT</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>): 1.3.0</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>: AWS</li>
<li><strong>OS</strong> (e.g. from /etc/os-release): the one used by kube-up.sh</li>
<li><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>): the one used by kube-up.sh</li>
<li><strong>Install tools</strong>: kube-up.sh</li>
<li><strong>Others</strong>:</li>
</ul>
<p dir="auto"><strong>What happened</strong>:</p>
<p dir="auto">The <a href="https://github.com/kubernetes/kubernetes/blob/release-1.3.0/cluster/aws/util.sh#L667-L675">S3 bucket created by kube-up</a> is publicly accesible.</p>
<p dir="auto">Also, the <a href="https://github.com/kubernetes/kubernetes/blob/release-1.3.0/cluster/aws/templates/iam/kubernetes-minion-policy.json#L8">S3 IAM permissions</a> don't respect the value of the <code class="notranslate">AWS_S3_BUCKET</code> env variable and are hardcoded to <code class="notranslate">kubernetes-*</code></p>
<p dir="auto"><strong>What you expected to happen</strong>:</p>
<p dir="auto">I don't think the bucket should be public.</p>
<p dir="auto">If it is public for a good reason, the IAM policies shouldn't contain explicit permission for S3 or at the very least they should follow the bucket name set by <code class="notranslate">AWS_S3_BUCKET</code></p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):</p>
<p dir="auto">Just calling <code class="notranslate">kube-up.sh</code></p>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>
<p dir="auto">Not really</p>