<p>I have been messing around with openshift and reading as much documentation as i can. Yet, the authentication performed by default(using admin .kubeconfig) puzzles me.</p>

<p>1)Are client-certificate-data and client-key-data the same as the admin certificate and key? I ask this because the contents of the certificate/key files are not the same as in .kubeconfig.</p>

<p>2).kubeconfig (AFAIK) is used to authenticate agains a kubernetes master. Yet, in OpenShift we are authentication against OpenShift master (right?). Why using .kubeconfig?</p>

<p>Kinds regards and thank you for your patience.</p>

<p>OpenShift builds on top of Kubernetes - it exposes both the OpenShift APIs (builds, deployments, images, projects) and the Kubernetes APIs (pods, replication controllers, services).  A client connecting to OpenShift will use both sets of APIs.  OpenShift <em>can</em> run on top of an existing Kubernetes cluster, in which case it will proxy API calls to the Kubernetes master and then apply security policy on top (via the OpenShift policy engine which may eventually become part of Kube).</p>

<p>So, the client is really an extension of Kubectl that offers some additional functionality, and it can use .kubeconfig to be consistent with a Kubectl setup.  You can talk to an OpenShift cluster via kubectl, so vice versa seems fair. </p>

<p>The client-certificate-data and key-data are base64 encoded versions of the files on disk.  They should be the same once you decode them.  We do that so the .kubeconfig can be shipped around as one unit, but you can also set it up to reference files on disk.</p>
