Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.8
* 'master' of https://github.com/kubernetes/kubernetes.github.io: (32 commits) Fixed broken link to Pods concept documentation (#5223) Update some docs in /cn/docs (#4842) Update deployment.md fix the command output Translate into chinese about NetworkPolicy rootsongjc-pr-20170815 fix typo fix the command output Translate into chinese about GPU index-pr-2017-08-15 Example links use kubernetes/examples Make caret for version drop-down more visible fix typo:ConfigMap fix the command output Fixed incorrect links for YAML files Clean up the index page. Remove broken link. Update pod names to match what's in the spec. Update daemonset.md Update configure-aggregation-layer.md ...
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.
|
||||
|
||||
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
|
||||
|
||||
Client certificate authentication is enabled by passing the `--client-ca-file=SOMEFILE`
|
||||
@@ -685,14 +689,6 @@ rules:
|
||||
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
|
||||
|
||||
### 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.
|
||||
..* 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/).
|
||||
* **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
|
||||
|
||||
@@ -136,11 +115,12 @@ to determine what access an authorizer is granting.
|
||||
You must include a flag in your policy to indicate which authorization module your policies include:
|
||||
|
||||
The following flags can be used:
|
||||
- `--authorization-mode=ABAC` Attribute-Based Access Control (ABAC) mode allows you to configure policies using local files.
|
||||
- `--authorization-mode=RBAC` Role-based access control (RBAC) mode allows you to create and store policies using the Kubernetes API.
|
||||
- `--authorization-mode=Webhook` WebHook is an HTTP callback mode that allows you to manage authorization using a remote REST.
|
||||
- `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing.
|
||||
- `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests.
|
||||
|
||||
* `--authorization-mode=ABAC` Attribute-Based Access Control (ABAC) mode allows you to configure policies using local files.
|
||||
* `--authorization-mode=RBAC` Role-based access control (RBAC) mode allows you to create and store policies using the Kubernetes API.
|
||||
* `--authorization-mode=Webhook` WebHook is an HTTP callback mode that allows you to manage authorization using a remote REST.
|
||||
* `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing.
|
||||
* `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests.
|
||||
|
||||
You can choose more than one authorization module. If one of the modes is `AlwaysAllow`, then it overrides the other modes and all API requests are allowed.
|
||||
|
||||
|
||||
@@ -82,7 +82,7 @@ data:
|
||||
|
||||
The type of the secret must be `bootstrap.kubernetes.io/token` and the name must
|
||||
be `bootstrap-token-<token id>`. It must also exist in the `kube-system`
|
||||
namespace. `description` is a human readable discription that should not be
|
||||
namespace. `description` is a human readable description that should not be
|
||||
used for machine readable information. The Token ID and Secret are included in
|
||||
the data dictionary.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user