Merge pull request #4727 from ericchiang/auth-remove-custom-module
docs/admin: encourage out-of-tree auth-N/Z integrations
This commit is contained in:
@@ -60,6 +60,10 @@ The API server does not guarantee the order authenticators run in.
|
|||||||
|
|
||||||
The `system:authenticated` group is included in the list of groups for all authenticated users.
|
The `system:authenticated` group is included in the list of groups for all authenticated users.
|
||||||
|
|
||||||
|
Integrations with other authentication protocols (LDAP, SAML, Kerberos, alternate x509 schemes, etc)
|
||||||
|
can be accomplished using an [authenticating proxy](#authenticating-proxy) or the
|
||||||
|
[authentication webhook](#webhook-token-authentication).
|
||||||
|
|
||||||
### X509 Client Certs
|
### X509 Client Certs
|
||||||
|
|
||||||
Client certificate authentication is enabled by passing the `--client-ca-file=SOMEFILE`
|
Client certificate authentication is enabled by passing the `--client-ca-file=SOMEFILE`
|
||||||
@@ -685,14 +689,6 @@ rules:
|
|||||||
resourceNames: ["view", "development"]
|
resourceNames: ["view", "development"]
|
||||||
```
|
```
|
||||||
|
|
||||||
## Plugin Development
|
|
||||||
|
|
||||||
We plan for the Kubernetes API server to issue tokens after the user has been
|
|
||||||
(re)authenticated by a *bedrock* authentication provider external to Kubernetes.
|
|
||||||
We also plan to make it easy to develop modules that interface between
|
|
||||||
Kubernetes and a bedrock authentication provider (e.g. github.com, google.com,
|
|
||||||
enterprise directory, kerberos, etc.)
|
|
||||||
|
|
||||||
## APPENDIX
|
## APPENDIX
|
||||||
|
|
||||||
### Creating Certificates
|
### Creating Certificates
|
||||||
|
|||||||
@@ -65,27 +65,6 @@ of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authoriz
|
|||||||
..* As of 1.6 RBAC mode is in beta.
|
..* As of 1.6 RBAC mode is in beta.
|
||||||
..* To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
|
..* To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
|
||||||
* **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/admin/authorization/webhook/).
|
* **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/admin/authorization/webhook/).
|
||||||
* **Custom Modules** - You can create custom modules for using with Kubernetes. To learn more, see **Custom Modules** below.
|
|
||||||
|
|
||||||
### Custom Modules
|
|
||||||
Other implementations can be developed fairly easily. The APIserver calls the Authorizer interface:
|
|
||||||
|
|
||||||
```go
|
|
||||||
type Authorizer interface {
|
|
||||||
Authorize(a Attributes) error
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
to determine whether or not to allow each API action.
|
|
||||||
|
|
||||||
An authorization plugin is a module that implements this interface.
|
|
||||||
Authorization plugin code goes in `pkg/auth/authorizer/$MODULENAME`.
|
|
||||||
|
|
||||||
An authorization module can be completely implemented in go, or can call out
|
|
||||||
to a remote authorization service. Authorization modules can implement
|
|
||||||
their own caching to reduce the cost of repeated authorization calls with the
|
|
||||||
same or similar arguments. Developers should then consider the interaction
|
|
||||||
between caching and revocation of permissions.
|
|
||||||
|
|
||||||
#### Checking API Access
|
#### Checking API Access
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user