Minor documentation cleanup (#7826)
* clarify link * Add section headers * console blocks * grpc example json was not valid * multi-tls update text The preceding point 1 related to4f2cb51ef8/ingress/controllers/nginx/examples/ingress.yamland the deployments referenced in4f2cb51ef8/ingress/controllers/nginx/examples/README.mdThey are not relevant to the current instructions. * add whitespace around parens * grammar setup would be a proper noun, but it is not the intended concept, which is a state * grammar * is-only * via * Use bullets for choices * ingress-controller nginx is a distinct brand. generally this repo talks about ingress-controller, although it is quite inconsistent about how... * drop stray paren * OAuth is a brand and needs an article here also GitHub is a brand * Indent text under numbered lists * use e.g. * Document that customer header config maps changes do not trigger updates This should be removed if https://github.com/kubernetes/ingress-nginx/issues/5238 is fixed. * article * period * infinitive verb + period * clarify that the gRPC server is responsible for listening for TCP traffic and not some other part of the backend application * avoid using ; and reword * whitespace * brand: gRPC * only-does is the right form `for` adds nothing here * spelling: GitHub * punctuation `;` is generally not the right punctuation... * drop stray `to` * sentence * backticks * fix link * Improve readability of compare/vs * Renumber list * punctuation * Favor Ingress-NGINX and Ingress NGINX * Simplify custom header restart text * Undo typo damage Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
This commit is contained in:
Josh Soref
GitHub
parent
784f9c53bb
commit
1614027cd4
27 changed files with 208 additions and 169 deletions
|
|
@ -3,6 +3,8 @@
|
|||
This example shows how to add authentication in a Ingress rule using a secret that contains a file generated with `htpasswd`.
|
||||
It's important the file generated is named `auth` (actually - that the secret has a key `data.auth`), otherwise the ingress-controller returns a 503.
|
||||
|
||||
## Create htpasswd file
|
||||
|
||||
```console
|
||||
$ htpasswd -c auth foo
|
||||
New password: <bar>
|
||||
|
|
@ -11,11 +13,15 @@ Re-type new password:
|
|||
Adding password for user foo
|
||||
```
|
||||
|
||||
## Convert htpasswd into a secret
|
||||
|
||||
```console
|
||||
$ kubectl create secret generic basic-auth --from-file=auth
|
||||
secret "basic-auth" created
|
||||
```
|
||||
|
||||
## Examine secret
|
||||
|
||||
```console
|
||||
$ kubectl get secret basic-auth -o yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -28,8 +34,10 @@ metadata:
|
|||
type: Opaque
|
||||
```
|
||||
|
||||
## Using kubectl, create an ingress tied to the basic-auth secret
|
||||
|
||||
```console
|
||||
echo "
|
||||
$ echo "
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
|
|
@ -57,6 +65,8 @@ spec:
|
|||
" | kubectl create -f -
|
||||
```
|
||||
|
||||
## Use curl to confirm authorization is required by the ingress
|
||||
|
||||
```
|
||||
$ curl -v http://10.2.29.4/ -H 'Host: foo.bar.com'
|
||||
* Trying 10.2.29.4...
|
||||
|
|
@ -84,6 +94,8 @@ $ curl -v http://10.2.29.4/ -H 'Host: foo.bar.com'
|
|||
* Connection #0 to host 10.2.29.4 left intact
|
||||
```
|
||||
|
||||
## Use curl with the correct credentials to connect to the ingress
|
||||
|
||||
```
|
||||
$ curl -v http://10.2.29.4/ -H 'Host: foo.bar.com' -u 'foo:bar'
|
||||
* Trying 10.2.29.4...
|
||||
|
|
|
|||
|
|
@ -1,11 +1,12 @@
|
|||
# Client Certificate Authentication
|
||||
|
||||
It is possible to enable Client-Certificate Authentication by adding additional annotations to your Ingress Resource.
|
||||
Before getting started you must have the following Certificates Setup:
|
||||
|
||||
1. CA certificate and Key(Intermediate Certs need to be in CA)
|
||||
2. Server Certificate(Signed by CA) and Key (CN should be equal the hostname you will use)
|
||||
3. Client Certificate(Signed by CA) and Key
|
||||
Before getting started you must have the following Certificates configured:
|
||||
|
||||
1. CA certificate and Key (Intermediate Certs need to be in CA)
|
||||
2. Server Certificate (Signed by CA) and Key (CN should be equal the hostname you will use)
|
||||
3. Client Certificate (Signed by CA) and Key
|
||||
|
||||
For more details on the generation process, checkout the Prerequisite [docs](../../PREREQUISITES.md#client-certificate-authentication).
|
||||
|
||||
|
|
@ -15,13 +16,13 @@ You can have as many certificates as you want. If they're in the binary DER form
|
|||
openssl x509 -in certificate.der -inform der -out certificate.crt -outform pem
|
||||
```
|
||||
|
||||
Then, you can concatenate them all in only one file, named 'ca.crt' as the following:
|
||||
Then, you can concatenate them all into one file, named 'ca.crt' with the following:
|
||||
|
||||
```bash
|
||||
cat certificate1.crt certificate2.crt certificate3.crt >> ca.crt
|
||||
```
|
||||
|
||||
**Note:** Make sure that the Key Size is greater than 1024 and Hashing Algorithm(Digest) is something better than md5
|
||||
**Note:** Make sure that the Key Size is greater than 1024 and Hashing Algorithm (Digest) is something better than md5
|
||||
for each certificate generated. Otherwise you will receive an error.
|
||||
|
||||
## Creating Certificate Secrets
|
||||
|
|
@ -29,7 +30,7 @@ for each certificate generated. Otherwise you will receive an error.
|
|||
There are many different ways of configuring your secrets to enable Client-Certificate
|
||||
Authentication to work properly.
|
||||
|
||||
1. You can create a secret containing just the CA certificate and another
|
||||
* You can create a secret containing just the CA certificate and another
|
||||
Secret containing the Server Certificate which is Signed by the CA.
|
||||
|
||||
```bash
|
||||
|
|
@ -37,14 +38,14 @@ Authentication to work properly.
|
|||
kubectl create secret generic tls-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key
|
||||
```
|
||||
|
||||
2. You can create a secret containing CA certificate along with the Server
|
||||
Certificate, that can be used for both TLS and Client Auth.
|
||||
* You can create a secret containing CA certificate along with the Server
|
||||
Certificate that can be used for both TLS and Client Auth.
|
||||
|
||||
```bash
|
||||
kubectl create secret generic ca-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key --from-file=ca.crt=ca.crt
|
||||
```
|
||||
|
||||
3. If you want to also enable Certificate Revocation List verification you can
|
||||
* If you want to also enable Certificate Revocation List verification you can
|
||||
create the secret also containing the CRL file in PEM format:
|
||||
```bash
|
||||
kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt --from-file=ca.crl=ca.crl
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# External Basic Authentication
|
||||
|
||||
### Example 1:
|
||||
### Example 1
|
||||
|
||||
Use an external service (Basic Auth) located in `https://httpbin.org`
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ status:
|
|||
$
|
||||
```
|
||||
|
||||
Test 1: no username/password (expect code 401)
|
||||
## Test 1: no username/password (expect code 401)
|
||||
|
||||
```console
|
||||
$ curl -k http://172.17.4.99 -v -H 'Host: external-auth-01.sample.com'
|
||||
|
|
@ -74,7 +74,8 @@ $ curl -k http://172.17.4.99 -v -H 'Host: external-auth-01.sample.com'
|
|||
* Connection #0 to host 172.17.4.99 left intact
|
||||
```
|
||||
|
||||
Test 2: valid username/password (expect code 200)
|
||||
## Test 2: valid username/password (expect code 200)
|
||||
|
||||
```
|
||||
$ curl -k http://172.17.4.99 -v -H 'Host: external-auth-01.sample.com' -u 'user:passwd'
|
||||
* Rebuilt URL to: http://172.17.4.99/
|
||||
|
|
@ -121,7 +122,8 @@ BODY:
|
|||
-no body in request-
|
||||
```
|
||||
|
||||
Test 3: invalid username/password (expect code 401)
|
||||
## Test 3: invalid username/password (expect code 401)
|
||||
|
||||
```
|
||||
curl -k http://172.17.4.99 -v -H 'Host: external-auth-01.sample.com' -u 'user:user'
|
||||
* Rebuilt URL to: http://172.17.4.99/
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ The `auth-url` and `auth-signin` annotations allow you to use an external
|
|||
authentication provider to protect your Ingress resources.
|
||||
|
||||
!!! Important
|
||||
This annotation requires `ingress-nginx-controller v0.9.0` or greater.)
|
||||
This annotation requires `ingress-nginx-controller v0.9.0` or greater.
|
||||
|
||||
### Key Detail
|
||||
|
||||
|
|
@ -32,45 +32,47 @@ metadata:
|
|||
### Example: OAuth2 Proxy + Kubernetes-Dashboard
|
||||
|
||||
This example will show you how to deploy [`oauth2_proxy`](https://github.com/pusher/oauth2_proxy)
|
||||
into a Kubernetes cluster and use it to protect the Kubernetes Dashboard using github as oAuth2 provider
|
||||
into a Kubernetes cluster and use it to protect the Kubernetes Dashboard using GitHub as the OAuth2 provider.
|
||||
|
||||
#### Prepare
|
||||
|
||||
1. Install the kubernetes dashboard
|
||||
|
||||
```console
|
||||
kubectl create -f https://raw.githubusercontent.com/kubernetes/kops/master/addons/kubernetes-dashboard/v1.10.1.yaml
|
||||
```
|
||||
```console
|
||||
kubectl create -f https://raw.githubusercontent.com/kubernetes/kops/master/addons/kubernetes-dashboard/v1.10.1.yaml
|
||||
```
|
||||
|
||||
2. Create a [custom Github OAuth application](https://github.com/settings/applications/new)
|
||||
2. Create a [custom GitHub OAuth application](https://github.com/settings/applications/new)
|
||||
|
||||
|
||||
|
||||
|
||||
- Homepage URL is the FQDN in the Ingress rule, like `https://foo.bar.com`
|
||||
- Authorization callback URL is the same as the base FQDN plus `/oauth2/callback`, like `https://foo.bar.com/oauth2/callback`
|
||||
- Homepage URL is the FQDN in the Ingress rule, like `https://foo.bar.com`
|
||||
- Authorization callback URL is the same as the base FQDN plus `/oauth2/callback`, like `https://foo.bar.com/oauth2/callback`
|
||||
|
||||
|
||||
|
||||
|
||||
3. Configure oauth2_proxy values in the file [`oauth2-proxy.yaml`](https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/docs/examples/auth/oauth-external-auth/oauth2-proxy.yaml) with the values:
|
||||
|
||||
- OAUTH2_PROXY_CLIENT_ID with the github `<Client ID>`
|
||||
- OAUTH2_PROXY_CLIENT_SECRET with the github `<Client Secret>`
|
||||
- OAUTH2_PROXY_COOKIE_SECRET with value of `python -c 'import os,base64; print(base64.b64encode(os.urandom(16)).decode("ascii"))'`
|
||||
- OAUTH2_PROXY_CLIENT_ID with the github `<Client ID>`
|
||||
- OAUTH2_PROXY_CLIENT_SECRET with the github `<Client Secret>`
|
||||
- OAUTH2_PROXY_COOKIE_SECRET with value of `python -c 'import os,base64; print(base64.b64encode(os.urandom(16)).decode("ascii"))'`
|
||||
|
||||
4. Customize the contents of the file [`dashboard-ingress.yaml`](https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/docs/examples/auth/oauth-external-auth/dashboard-ingress.yaml):
|
||||
|
||||
Replace `__INGRESS_HOST__` with a valid FQDN and `__INGRESS_SECRET__` with a Secret with a valid SSL certificate.
|
||||
Replace `__INGRESS_HOST__` with a valid FQDN and `__INGRESS_SECRET__` with a Secret with a valid SSL certificate.
|
||||
|
||||
5. Deploy the oauth2 proxy and the ingress rules running:
|
||||
|
||||
```console
|
||||
$ kubectl create -f oauth2-proxy.yaml,dashboard-ingress.yaml
|
||||
```
|
||||
```console
|
||||
$ kubectl create -f oauth2-proxy.yaml,dashboard-ingress.yaml
|
||||
```
|
||||
|
||||
Test the oauth integration accessing the configured URL, like `https://foo.bar.com`
|
||||
### Test
|
||||
|
||||
Test the oauth integration accessing the configured URL, e.g. `https://foo.bar.com`
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue