Update authorization-rbac links (#9463)
* update authorization-rbac links * fix broken links * undo modification of cn content
This commit is contained in:
Bob Killen
k8s-ci-robot
parent
76b7f9cb1a
commit
2ee2e9d5bb
|
|
@ -6,7 +6,7 @@ url: /blog/2017/03/Kubernetes-1.6-Multi-User-Multi-Workloads-At-Scale
|
|||
---
|
||||
Today we’re announcing the release of Kubernetes 1.6.
|
||||
|
||||
In this release the community’s focus is on scale and automation, to help you deploy multiple workloads to multiple users on a cluster. We are announcing that 5,000 node clusters are supported. We moved dynamic storage provisioning to _stable_. Role-based access control ([RBAC](https://kubernetes.io/docs/admin/authorization/rbac/)), [kubefed](https://kubernetes.io/docs/tutorials/federation/set-up-cluster-federation-kubefed/), [kubeadm](https://kubernetes.io/docs/getting-started-guides/kubeadm/), and several scheduling features are moving to _beta_. We have also added intelligent defaults throughout to enable greater automation out of the box.
|
||||
In this release the community’s focus is on scale and automation, to help you deploy multiple workloads to multiple users on a cluster. We are announcing that 5,000 node clusters are supported. We moved dynamic storage provisioning to _stable_. Role-based access control ([RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)), [kubefed](https://kubernetes.io/docs/tutorials/federation/set-up-cluster-federation-kubefed/), [kubeadm](https://kubernetes.io/docs/getting-started-guides/kubeadm/), and several scheduling features are moving to _beta_. We have also added intelligent defaults throughout to enable greater automation out of the box.
|
||||
|
||||
**What’s New**
|
||||
|
||||
|
|
@ -14,7 +14,7 @@ In this release the community’s focus is on scale and automation, to help you
|
|||
|
||||
For users who want to scale beyond 5,000 nodes or spread across multiple regions or clouds, [federation](https://kubernetes.io/docs/concepts/cluster-administration/federation/) lets you combine multiple Kubernetes clusters and address them through a single API endpoint. In this release, the [kubefed](https://kubernetes.io//docs/tutorials/federation/set-up-cluster-federation-kubefed) command line utility graduated to _beta_ - with improved support for on-premise clusters. kubefed now [automatically configures](https://kubernetes.io//docs/tutorials/federation/set-up-cluster-federation-kubefed.md#kube-dns-configuration) kube-dns on joining clusters and can pass arguments to federated components.
|
||||
|
||||
**Security and Setup** : Users concerned with security will find that [RBAC](https://kubernetes.io//docs/admin/authorization/rbac), now _beta_ adds a significant security benefit through more tightly scoped default roles for system components. The default RBAC policies in 1.6 grant scoped permissions to control-plane components, nodes, and controllers. RBAC allows cluster administrators to selectively grant particular users or service accounts fine-grained access to specific resources on a per-namespace basis. RBAC users upgrading from 1.5 to 1.6 should view the guidance [here](https://kubernetes.io//docs/admin/authorization/rbac.md#upgrading-from-15).
|
||||
**Security and Setup** : Users concerned with security will find that [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac), now _beta_ adds a significant security benefit through more tightly scoped default roles for system components. The default RBAC policies in 1.6 grant scoped permissions to control-plane components, nodes, and controllers. RBAC allows cluster administrators to selectively grant particular users or service accounts fine-grained access to specific resources on a per-namespace basis. RBAC users upgrading from 1.5 to 1.6 should view the guidance [here](https://kubernetes.io/docs/reference/access-authn-authz/rbac#upgrading-from-1-5).
|
||||
|
||||
Users looking for an easy way to provision a secure cluster on physical or cloud servers can use [kubeadm](https://kubernetes.io/docs/getting-started-guides/kubeadm/), which is now _beta_. kubeadm has been enhanced with a set of command line flags and a base feature set that includes RBAC setup, use of the [Bootstrap Token system](http://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/) and an enhanced [Certificates API](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/).
|
||||
|
||||
|
|
|
|||
|
|
@ -42,11 +42,11 @@ A RoleBinding maps a Role to a user or set of users, granting that Role's permis
|
|||
[](https://1.bp.blogspot.com/-ixDe91-cnqw/WOa0auxC0mI/AAAAAAAABBs/4LxVsr6shEgTYqUapt5QPISUeuTuztVwwCEw/s1600/rbac2.png)
|
||||
|
||||
|
||||
Additionally there are cluster roles and cluster role bindings to consider. Cluster roles and cluster role bindings function like roles and role bindings except they have wider scope. The exact differences and how cluster roles and cluster role bindings interact with roles and role bindings are covered in the [Kubernetes documentation](https://kubernetes.io/docs/admin/authorization/rbac/#rolebinding-and-clusterrolebinding).
|
||||
Additionally there are cluster roles and cluster role bindings to consider. Cluster roles and cluster role bindings function like roles and role bindings except they have wider scope. The exact differences and how cluster roles and cluster role bindings interact with roles and role bindings are covered in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding).
|
||||
|
||||
**RBAC in Kubernetes**
|
||||
|
||||
RBAC is now deeply integrated into Kubernetes and used by the system components to grant the permissions necessary for them to function. [System roles](https://kubernetes.io/docs/admin/authorization/rbac/#default-roles-and-role-bindings) are typically prefixed with system: so they can be easily recognized.
|
||||
RBAC is now deeply integrated into Kubernetes and used by the system components to grant the permissions necessary for them to function. [System roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) are typically prefixed with system: so they can be easily recognized.
|
||||
|
||||
|
||||
```
|
||||
|
|
@ -76,7 +76,7 @@ system:controller:certificate-controller ClusterRole.v1beta1.rbac.authorization.
|
|||
|
||||
The RBAC system roles have been expanded to cover the necessary permissions for running a Kubernetes cluster with RBAC only.
|
||||
|
||||
During the permission translation from ABAC to RBAC, some of the permissions that were enabled by default in many deployments of ABAC authorized clusters were identified as unnecessarily broad and were [scoped down](https://kubernetes.io/docs/admin/authorization/rbac/#upgrading-from-15) in RBAC. The area most likely to impact workloads on a cluster is the permissions available to service accounts. With the permissive ABAC configuration, requests from a pod using the pod mounted token to authenticate to the API server have broad authorization. As a concrete example, the curl command at the end of this sequence will return a JSON formatted result when ABAC is enabled and an error when only RBAC is enabled.
|
||||
During the permission translation from ABAC to RBAC, some of the permissions that were enabled by default in many deployments of ABAC authorized clusters were identified as unnecessarily broad and were [scoped down](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#upgrading-from-1-5) in RBAC. The area most likely to impact workloads on a cluster is the permissions available to service accounts. With the permissive ABAC configuration, requests from a pod using the pod mounted token to authenticate to the API server have broad authorization. As a concrete example, the curl command at the end of this sequence will return a JSON formatted result when ABAC is enabled and an error when only RBAC is enabled.
|
||||
|
||||
|
||||
```
|
||||
|
|
@ -96,13 +96,13 @@ During the permission translation from ABAC to RBAC, some of the permissions tha
|
|||
|
||||
Any applications you run in your Kubernetes cluster that interact with the Kubernetes API have the potential to be affected by the permissions changes when transitioning from ABAC to RBAC.
|
||||
|
||||
To smooth the transition from ABAC to RBAC, you can create Kubernetes 1.6 clusters with both [ABAC and RBAC authorizers](https://kubernetes.io/docs/admin/authorization/rbac/#parallel-authorizers) enabled. When both ABAC and RBAC are enabled, authorization for a resource is granted if either authorization policy grants access. However, under that configuration the most permissive authorizer is used and it will not be possible to use RBAC to fully control permissions.
|
||||
To smooth the transition from ABAC to RBAC, you can create Kubernetes 1.6 clusters with both [ABAC and RBAC authorizers](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#parallel-authorizers) enabled. When both ABAC and RBAC are enabled, authorization for a resource is granted if either authorization policy grants access. However, under that configuration the most permissive authorizer is used and it will not be possible to use RBAC to fully control permissions.
|
||||
|
||||
At this point, RBAC is complete enough that ABAC support should be considered deprecated going forward. It will still remain in Kubernetes for the foreseeable future but development attention is focused on RBAC.
|
||||
|
||||
|
||||
|
||||
Two different talks at the at the Google Cloud Next conference touched on RBAC related changes in Kubernetes 1.6, jump to the relevant parts [here](https://www.youtube.com/watch?v=Cd4JU7qzYbE#t=8m01s) and [here](https://www.youtube.com/watch?v=18P7cFc6nTU#t=41m06s). For more detailed information about using RBAC in Kubernetes 1.6 read the full [RBAC documentation](https://kubernetes.io/docs/admin/authorization/rbac/).
|
||||
Two different talks at the at the Google Cloud Next conference touched on RBAC related changes in Kubernetes 1.6, jump to the relevant parts [here](https://www.youtube.com/watch?v=Cd4JU7qzYbE#t=8m01s) and [here](https://www.youtube.com/watch?v=18P7cFc6nTU#t=41m06s). For more detailed information about using RBAC in Kubernetes 1.6 read the full [RBAC documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).
|
||||
|
||||
|
||||
**Get Involved**
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ We’re pleased to announce the delivery of Kubernetes 1.8, our third release th
|
|||
|
||||
## Spotlight on security
|
||||
|
||||
Kubernetes 1.8 graduates support for [role based access control](https://en.wikipedia.org/wiki/Role-based_access_control) (RBAC) to stable. RBAC allows cluster administrators to [dynamically define roles](https://kubernetes.io/docs/admin/authorization/rbac/) to enforce access policies through the Kubernetes API. Beta support for filtering outbound traffic through [network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) augments existing support for filtering inbound traffic to a pod. RBAC and Network Policies are two powerful tools for enforcing organizational and regulatory security requirements within Kubernetes.
|
||||
Kubernetes 1.8 graduates support for [role based access control](https://en.wikipedia.org/wiki/Role-based_access_control) (RBAC) to stable. RBAC allows cluster administrators to [dynamically define roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) to enforce access policies through the Kubernetes API. Beta support for filtering outbound traffic through [network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) augments existing support for filtering inbound traffic to a pod. RBAC and Network Policies are two powerful tools for enforcing organizational and regulatory security requirements within Kubernetes.
|
||||
|
||||
|
||||
Transport Layer Security (TLS) [certificate rotation](https://kubernetes.io/docs/admin/kubelet-tls-bootstrapping/) for the Kubelet graduates to beta. Automatic certificate rotation eases secure cluster operation.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: /blog/2017/10/Using-Rbac-Generally-Available-18
|
|||
---
|
||||
**_Editor's note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/10/five-days-of-kubernetes-18) on what's new in Kubernetes 1.8. Today’s post comes from Eric Chiang, software engineer, CoreOS, and SIG-Auth co-lead._**
|
||||
|
||||
Kubernetes 1.8 represents a significant milestone for the [role-based access control (RBAC) authorizer](https://kubernetes.io/docs/admin/authorization/rbac/), which was promoted to GA in this release. RBAC is a mechanism for controlling access to the Kubernetes API, and since its [beta in 1.6](https://kubernetes.io/blog/2017/04/rbac-support-in-kubernetes), many Kubernetes clusters and provisioning strategies have enabled it by default.
|
||||
Kubernetes 1.8 represents a significant milestone for the [role-based access control (RBAC) authorizer](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), which was promoted to GA in this release. RBAC is a mechanism for controlling access to the Kubernetes API, and since its [beta in 1.6](https://kubernetes.io/blog/2017/04/rbac-support-in-kubernetes), many Kubernetes clusters and provisioning strategies have enabled it by default.
|
||||
|
||||
Going forward, we expect to see RBAC become a fundamental building block for securing Kubernetes clusters. This post explores using RBAC to manage user and application access to the Kubernetes API.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ Customization approaches can be broadly divided into *configuration*, which only
|
|||
|
||||
Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
|
||||
|
||||
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/admin/authorization/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
|
||||
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
|
||||
|
||||
## Extensions
|
||||
|
||||
|
|
|
|||
|
|
@ -80,8 +80,8 @@ pod's service account (see [example](#run-another-pod)).
|
|||
|
||||
### Via RBAC
|
||||
|
||||
[RBAC](/docs/admin/authorization/rbac/) is a standard Kubernetes authorization
|
||||
mode, and can easily be used to authorize use of policies.
|
||||
[RBAC](/docs/reference/access-authn-authz/rbac/) is a standard Kubernetes
|
||||
authorization mode, and can easily be used to authorize use of policies.
|
||||
|
||||
First, a `Role` or `ClusterRole` needs to grant access to `use` the desired
|
||||
policies. The rules to grant access look like this:
|
||||
|
|
@ -136,8 +136,8 @@ paired with system groups to grant access to all pods run in the namespace:
|
|||
```
|
||||
|
||||
For more examples of RBAC bindings, see [Role Binding
|
||||
Examples](/docs/admin/authorization/rbac#role-binding-examples). For a complete
|
||||
example of authorizing a PodSecurityPolicy, see
|
||||
Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples).
|
||||
For a complete example of authorizing a PodSecurityPolicy, see
|
||||
[below](#example).
|
||||
|
||||
|
||||
|
|
@ -149,7 +149,7 @@ and must not have superuser permissions. Otherwise requests would bypass
|
|||
authentication and authorization modules, all PodSecurityPolicy objects would be
|
||||
allowed, and users would be able to create privileged containers. For more details
|
||||
on configuring Controller Manager authorization, see [Controller
|
||||
Roles](/docs/admin/authorization/rbac/#controller-roles).
|
||||
Roles](/docs/reference/access-authn-authz/rbac/#controller-roles).
|
||||
|
||||
## Policy Order
|
||||
|
||||
|
|
|
|||
|
|
@ -527,9 +527,9 @@ parameters:
|
|||
cluster, and `skuName` and `location` are ignored.
|
||||
|
||||
During provision, a secret is created for mounting credentials. If the cluster
|
||||
has enabled both [RBAC](/docs/admin/authorization/rbac/) and
|
||||
[Controller Roles](/docs/admin/authorization/rbac/#controller-roles), add the
|
||||
`create` permission of resource `secret` for clusterrole
|
||||
has enabled both [RBAC](/docs/reference/access-authn-authz/rbac/) and
|
||||
[Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles),
|
||||
add the `create` permission of resource `secret` for clusterrole
|
||||
`system:controller:persistent-volume-binder`.
|
||||
|
||||
### Portworx Volume
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: RBAC (Role-Based Access Control)
|
||||
id: rbac
|
||||
date: 2018-04-12
|
||||
full_link: /docs/admin/authorization/rbac/
|
||||
full_link: /docs/reference/access-authn-authz/rbac/
|
||||
short_description: >
|
||||
Manages authorization decisions, allowing admins to dynamically configure access policies through the Kubernetes API.
|
||||
|
||||
|
|
|
|||
|
|
@ -170,14 +170,14 @@ Kubeadm kubeconfig files with identities for control plane components:
|
|||
- Have the CN `system:node:<hostname-lowercased>`
|
||||
- A kubeconfig file for controller-manager, `/etc/kubernetes/controller-manager.conf`; inside this file is embedded a client
|
||||
certificate with controller-manager identity. This client cert should have the CN `system:kube-controller-manager`, as defined
|
||||
by default [RBAC core components roles](/docs/admin/authorization/rbac/#core-component-roles)
|
||||
by default [RBAC core components roles](/docs/reference/access-authn-authz/rbac/#core-component-roles)
|
||||
- A kubeconfig file for scheduler, `/etc/kubernetes/scheduler.conf`; inside this file is embedded a client certificate with scheduler identity.
|
||||
This client cert should have the CN `system:kube-scheduler`, as defined by default [RBAC core components roles](/docs/admin/authorization/rbac/#core-component-roles)
|
||||
This client cert should have the CN `system:kube-scheduler`, as defined by default [RBAC core components roles](/docs/reference/access-authn-authz/rbac/#core-component-roles)
|
||||
|
||||
Additionally, a kubeconfig file for kubeadm to use itself and the admin is generated and save into the `/etc/kubernetes/admin.conf` file.
|
||||
The "admin" here is defined the actual person(s) that is administering the cluster and want to have full control (**root**) over the cluster.
|
||||
The embedded client certificate for admin should:
|
||||
- Be in the `system:masters` organization, as defined by default [RBAC user facing role bindings](/docs/admin/authorization/rbac/#user-facing-roles)
|
||||
- Be in the `system:masters` organization, as defined by default [RBAC user facing role bindings](/docs/reference/access-authn-authz/rbac/#user-facing-roles)
|
||||
- Include a CN, but that can be anything. Kubeadm uses the `kubernetes-admin` CN
|
||||
|
||||
Please note that:
|
||||
|
|
|
|||
|
|
@ -51,11 +51,12 @@ Consult the [authentication reference document](/docs/reference/access-authn-aut
|
|||
### API Authorization
|
||||
|
||||
Once authenticated, every API call is also expected to pass an authorization check. Kubernetes ships
|
||||
an integrated [Role-Based Access Control (RBAC)](/docs/admin/authorization/rbac/) component that matches an incoming user or group to a
|
||||
an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-authz/rbac/) component that matches an incoming user or group to a
|
||||
set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with
|
||||
resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box
|
||||
roles are provided that offer reasonable default separation of responsibility depending on what
|
||||
actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/) and [RBAC](/docs/admin/authorization/rbac/) authorizers together, in combination with the
|
||||
actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/)
|
||||
and [RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the
|
||||
[NodeRestriction](/docs/admin/admission-controllers/#noderestriction) admission plugin.
|
||||
|
||||
As with authentication, simple and broad roles may be appropriate for smaller clusters, but as
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ In Kubernetes, you configure access control:
|
|||
You also configure authorization. That is, you determine not just how users and services authenticate to the API server, or whether they have access, but also what resources they have access to. Role-based access control (RBAC) is the recommended mechanism for controlling authorization to Kubernetes resources. Other authorization modes are available for more specific use cases.
|
||||
|
||||
* [Authorization Overview](/docs/reference/access-authn-authz/authorization/)
|
||||
* [Using RBAC Authorization](/docs/admin/authorization/rbac/)
|
||||
* [Using RBAC Authorization](/docs/reference/access-authn-authz/rbac/)
|
||||
|
||||
You should create Secrets to hold sensitive data such as passwords, tokens, or keys. Be aware, however, that there are limitations to the protections that a Secret can provide. See [the Risks section of the Secrets documentation](/docs/concepts/configuration/secret/#risks).
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue