Change:
1. First we need a CA to later sign the client certificate: <del> ``` shell openssl req -nodes -new -x509 -keyout ca.key -out ca.crt ``` </del> <ins> ``` shell openssl req -nodes -new -x509 -keyout ca.key -out ca.crt ``` </ins> 2. Then we create a client cert signed by this CA for the user `development` in the superuser group `system:masters`: <del> ``` shell openssl req -out client.csr -new -newkey rsa:4096 -nodes -keyout client.key -subj "/CN=development/O=system:masters" openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt ``` </del> <ins> ``` shell openssl req -out client.csr -new -newkey rsa:4096 -nodes -keyout client.key -subj "/CN=development/O=system:masters" openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt ``` </ins> 3. As curl requires client certificates in p12 format with password, do the conversion: <del> ``` shell openssl pkcs12 -export -in ./client.crt -inkey ./client.key -out client.p12 -passout pass:password ``` </del> <ins> ``` shell openssl pkcs12 -export -in ./client.crt -inkey ./client.key -out client.p12 -passout pass:password ``` </ins> 4. With these keys and certs in-place, we start the server: <del> ``` shell etcd & sample-apiserver --secure-port 8443 --etcd-servers http://127.0.0.1:2379 --v=7  --client-ca-file ca.crt  --kubeconfig ~/.kube/config  --authentication-kubeconfig ~/.kube/config  --authorization-kubeconfig ~/.kube/config ``` The first kubeconfig is used for the shared informers to access Kubernetes resources. The second kubeconfig passed to `--authentication-kubeconfig` is used to satisfy the delegated authenticator. The third kubeconfig passed to `--authorized-kubeconfig` is used to satisfy the delegated authorizer. Neither the authenticator, nor the authorizer will actually be used: due to `--client-ca-file`, our development X.509 certificate is accepted and authenticates us as `system:masters` member. `system:masters` is the superuser group such that delegated authorization is skipped. </del> <ins> ``` shell etcd & sample-apiserver --secure-port 8443 --etcd-servers http://127.0.0.1:2379 --v=7  --client-ca-file ca.crt  --kubeconfig ~/.kube/config  --authentication-kubeconfig ~/.kube/config  --authorization-kubeconfig ~/.kube/config ``` The first kubeconfig is used for the shared informers to access Kubernetes resources. The second kubeconfig passed to `--authentication-kubeconfig` is used to satisfy the delegated authenticator. The third kubeconfig passed to `--authorized-kubeconfig` is used to satisfy the delegated authorizer. Neither the authenticator, nor the authorizer will actually be used: due to `--client-ca-file`, our development X.509 certificate is accepted and authenticates us as `system:masters` member. `system:masters` is the superuser group such that delegated authorization is skipped. </ins> 5. Use curl to access the server using the client certificate in p12 format for authentication: <del> ``` shell curl -fv -k --cert client.p12:password  https://localhost:8443/apis/wardle.k8s.io/v1alpha1/namespaces/default/flunders ``` </del> <ins> ``` shell curl -fv -k --cert client.p12:password  https://localhost:8443/apis/wardle.k8s.io/v1alpha1/namespaces/default/flunders ``` Or use wget: ``` shell wget -O- --no-check-certificate  --certificate client.crt --private-key client.key  https://localhost:8443/apis/wardle.k8s.io/v1alpha1/namespaces/default/flunders ``` </ins> Note: Recent OSX versions broke client certs with curl. On Mac try `brew install httpie` and then: <del> ``` shell http --verify=no --cert client.crt --cert-key client.key  https://localhost:8443/apis/wardle.k8s.io/v1alpha1/namespaces/default/flunders ``` </del> <ins> ``` shell http --verify=no --cert client.crt --cert-key client.key  https://localhost:8443/apis/wardle.k8s.io/v1alpha1/namespaces/default/flunders ``` </ins>

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: I wanted to test the latest version of the sample-apiserver. I still did not find instructions or a script for building it. I found the script, but that relies on the directory produced when building k/k. What you expected to happen: I expected this sample to have standalone build instructions or scripting. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I created a script of my own to build it:
Also: since the file has a fixed image reference, only someone who pushes to that image can use that file unmodified. The README should say something about this.
Also, the existing is not designed to be invoked by a developer who has done but rather is designed to work only in the context of a full build of k/k.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale Being addressed by