<p>I have an OpenShift server I'm trying to work on. When I use:</p>

<p><code>oc apply -f</code> </p>

<p>My request is successfully processed. </p>

<p>However, many tools I want to use for development expect <code>kubectl</code> to be used to connect to the cluster. In most circumstances, I can use <code>kubectl</code> with no problems. </p>

<p>However, in the case of <code>kubectl apply -f</code>, this fails with error:</p>

<p><code>Error from server (Forbidden): unknown</code></p>

<p>While running <code>oc apply -f</code> works as expected.</p>

<p>To try to bypass this, I created (on Windows) a symbolic link named "kubectl" to the <code>oc</code> executable. Unexpectedly, this caused the <code>oc</code> command to start behaving like the <code>kubectl</code> command, and again receiving the same error. </p>

<p>Calling the full path to the link, as well as simply renaming "oc.exe" to "kubectl.exe" produces the same error. I confirmed I was indeed calling the correct bianry by running <code>kubectl version</code>, and I received different results from the vanilla binary vs. the openshift wrapper.</p>

<p>Enabling verbose logging: <code>kubectl apply -f service.yaml --v 6</code> gives this output</p>

<pre><code>I0625 13:09:43.873985   11744 loader.go:357] Config loaded from file C:\Users\username/.kube/config
I0625 13:09:44.175973   11744 round_trippers.go:436] GET https://myhost:443/swagger-2.0.0.pb-v1 403 Forbidden in 286 milliseconds
I0625 13:09:44.179974   11744 helpers.go:201] server response object: [{
  "metadata": {},
  "status": "Failure",
  "message": "unknown",
  "reason": "Forbidden",
  "details": {
    "causes": [
      {
        "reason": "UnexpectedServerResponse",
        "message": "unknown"
      }
    ]
  },
  "code": 403
}]
</code></pre>

<p>Running using <code>oc apply -f service.yaml --v 6</code> gives almost the same result, except that after the initial 403 error, I get the following output:</p>

<pre><code>I0625 13:37:19.403259    7228 round_trippers.go:436] GET https://myhost:443/api 200 OK in 5 milliseconds
</code></pre>

<p>And the command continues on to work correctly.</p>

<p>Is there anyway I can bypass this odd behavior, and somehow use <code>kubectl</code> to successfully run <code>kubectl apply -f</code> against the OpenShift server?</p>

<p><strong>Edit:</strong></p>

<p>The <code>oc</code> binary wrapper uses kubectl 1.9.<br>
The vanilla <code>kubectl</code> command uses 1.10.<br>
The server is kubectl 1.6 and openshift 3.6.</p>

Himself12794
<p>what client and server version do you have?</p>

<p>kubectl attempts to do client-side validation when it creates/applies objects. to do this, it first downloads the openapi schema. when making requests to an older server, that endpoint may not be recognized, and may result in a "forbidden" error</p>

<p>setting <code>--validate=false</code> when making the kubectl apply call will bypass that client-side validation (server-side validation is still performed)</p>
