* '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:
Andrew Chen
2017-09-01 17:20:29 -07:00
170 changed files with 7319 additions and 156 deletions
+4 -8
View File
@@ -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
+6 -26
View File
@@ -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.
+1 -1
View File
@@ -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.