<p>I have a Kubernetes question.</p>

<p>We have a master pod that can deploy other pods depending on the REST endpoint called. For example, if someone calls "/start_work" endpoint, it can deploy a worker pod to do the work related with this request.</p>

<p>This master pod is deployed with default ServiceAccount, and to allow it to deploy other pods, we had to give it cluster-admin access. We used ClusterRoleBinding to tie the default ServiceAccount to a cluster-admin role.</p>

<p>However, we have a more challenging problem now where our master pod is running in one cluster, but the worker pod needs to be deployed in another cluster. Does this sound achievable ? Giving the default ServiceAccount cluster-admin access can't help us if we're talking about another cluster, right?</p>

<p>Has anyone done this before? How did you achieve this ?</p>

<p>Thanks a ton.</p>

Sunny Patel
<blockquote>
  <p>However, we have a more challenging problem now where our master pod is running in one cluster, but the worker pod needs to be deployed in another cluster. Does this sound achievable ?</p>
</blockquote>

<p>Certainly, yes; you are free to provide credentials via any number of supported mechanisms that would give the Pod a well-formed KUBECONFIG that can talk to the remote cluster at whatever access level of your comfort. By <em>default</em> the injected <code>ServiceAccount</code> is trusted by only its own cluster, but there are seemingly infinite ways of providing the component parts or a fully formed KUBECONFIG into a Pod's filesystem, and then you're off to the races</p>

<blockquote>
  <p>Giving the default ServiceAccount cluster-admin access can't help us if we're talking about another cluster, right?</p>
</blockquote>

<p>That depends <em>(is always the answer!)</em> on whether the two clusters share a common CA root; if the answer is yes, then yes, <code>cluster-admin</code> on one will become <code>cluster-admin</code> on both. The <code>Subject</code> is determined by the <code>CN=</code> (and sometimes <code>OU=</code>/<code>O=</code>) of the presented x509 certificate, and its validity is determined by the chain-of-trust between the presented certificate and the api-server of the cluster</p>
