add preset RBAC roles and authorization documentation (#293)

* add preset RBAC roles and authorization documentation

- Adds a set of ClusterRoles and Roles to make it easier to bind to user accounts
- Adds a new docuemntation page for configuring Auth in Kubeapps

* small fixes in dashboard

* rename doc to access-control, link to doc from dashboard

* link to access-control doc from README

* updates the getting-started guide with auth setup

* fix screenshot title

README.md

@@ -26,9 +26,9 @@ kubeapps dashboard
 
 These commands will deploy Kubeapps in your cluster and launch a browser with the Kubeapps dashboard.
 
-![Dashboard main page](img/dashboard-login.png)
+![Dashboard login page](img/dashboard-login.png)
 
-Access to the dashboard requires authorization which is handled by Kubernetes API server. The dashboard only acts as a proxy and passes all auth information to it. In case of forbidden access corresponding warnings will be displayed in Dashboard.
+Access to the dashboard requires a Kubernetes API token to authenticate with the Kubernetes API server. Read the [Access Control](docs/access-control.md) documentation for more information on configuring users for Kubeapps.
 
 The following commands create a ServiceAccount and ClusterRoleBinding named `kubeapps-operator` which will enable the dashboard to authenticate and manage resources on the Kubernetes cluster:
 
@@ -43,6 +43,8 @@ Use the following command to reveal the authorization token that should be used
 kubectl get secret $(kubectl get serviceaccount kubeapps-operator -o jsonpath='{.secrets[].name}') -o jsonpath='{.data.token}' | base64 --decode
 ```
 
+**NOTE**: It's not recommended to create cluster-admin users for Kubeapps. Please refer to the [Access Control](docs/access-control.md) documentation to configure more fine-grained access.
+
 ![Dashboard main page](img/dashboard-home.png)
 
 To remove Kubeapps from your cluster, simply run:

dashboard/src/components/DeploymentForm/DeploymentForm.tsx

@@ -22,6 +22,12 @@ const RequiredRBACRoles: IRBACRole[] = [
     resource: "helmreleases",
     verbs: ["create", "patch"],
   },
+  {
+    apiGroup: "kubeapps.com",
+    namespace: "kubeapps",
+    resource: "apprepositories",
+    verbs: ["get"],
+  },
 ];
 
 interface IDeploymentFormProps {

dashboard/src/components/ErrorAlert/PermissionsErrorAlert.tsx

@@ -25,7 +25,15 @@ class PermissionsErrorPage extends React.Component<IPermissionsErrorPage> {
           <ul className="error__permisions-list">
             {roles.map((r, i) => <PermissionsListItem key={i} namespace={namespace} role={r} />)}
           </ul>
-          <p>See the documentation for more info on access control in Kubeapps.</p>
+          <p>
+            See the documentation for more info on{" "}
+            <a
+              href="https://github.com/kubeapps/kubeapps/blob/master/docs/access-control.md"
+              target="_blank"
+            >
+              access control in Kubeapps
+            </a>.
+          </p>
         </div>
       </div>
     );

dashboard/src/components/LoginForm/LoginForm.tsx

@@ -45,7 +45,13 @@ class LoginForm extends React.Component<ILoginFormProps, ILoginFormState> {
               </h2>
               <p>
                 Your cluster operator should provide you with a Kubernetes API token.{" "}
-                <a href="#">Click here</a> for more info on how to create and use Bearer Tokens.
+                <a
+                  href="https://github.com/kubeapps/kubeapps/blob/master/docs/access-control.md"
+                  target="_blank"
+                >
+                  Click here
+                </a>{" "}
+                for more info on how to create and use Bearer Tokens.
               </p>
               <div className="bg-skew__content">
                 <form onSubmit={this.handleSubmit}>

dashboard/src/components/ProvisionButton/index.tsx

@@ -189,7 +189,11 @@ class ProvisionButton extends React.Component<IProvisionButtonProps, IProvisionB
         parametersObject,
       );
       if (provisioned) {
-        push(`/services/instances/ns/${namespace}/${releaseName}`);
+        push(
+          `/services/brokers/${
+            selectedClass.spec.clusterServiceBrokerName
+          }/instances/ns/${namespace}/${releaseName}`,
+        );
       } else {
         this.setState({ isProvisioning: false });
       }

docs/access-control.md

@@ -0,0 +1,177 @@
+# Access Control in Kubeapps
+
+Kubeapps requires users to login with a Kubernetes API token in order to make
+requests to the Kubernetes API server as the user. This ensures that a certain
+user of Kubeapps is only permitted to view and manage applications that they
+have access to (for example, within a specific namespace). If a user does not
+have access to a particular resource, Kubeapps will display an error describing
+the required roles to access the resource.
+
+If your cluster supports [Token
+Authentication](https://kubernetes.io/docs/admin/authentication/) you may login
+with the same tokens. Alternatively, you can create Service Accounts for
+Kubeapps users. The examples below use a Service Account, as it is the most
+common scenario.
+
+## Service Accounts
+
+To create a Service Account for a user "example" in the "default" namespace, run
+the following:
+
+```
+kubectl create -n default serviceaccount example
+```
+
+To get the API token for this Service Account, run the following:
+
+```
+kubectl get -n default secret $(kubectl get -n default serviceaccount example -o jsonpath='{.secrets[].name}') -o jsonpath='{.data.token}' | base64 --decode
+```
+
+## Assigning Kubeapps User Roles
+
+Kubeapps will install a set of preset Roles and ClusterRoles in your cluster
+that you can bind to user or Service Accounts. Each Role and ClusterRole
+pertains to a certain operation within Kubeapps. This documentation describes
+the roles that should be applied to a user in order to perform operations within
+Kubeapps.
+
+### Applications
+
+#### Read access to Applications within a namespace
+
+In order to list and view Applications in a namespace, apply the
+`kubeapps-applications-read` ClusterRole in the desired namespace and the
+`kubeapps-tiller-state-read` Role in the `kubeapps` namespace:
+
+```
+kubectl create -n default rolebinding example-kubeapps-applications-read --clusterrole=kubeapps-applications-read --serviceaccount default:example
+kubectl create -n kubeapps rolebinding example-kubeapps-tiller-state-read --role=kubeapps-tiller-state-read --serviceaccount default:example
+```
+
+#### Write access to Applications within a namespace
+
+In order to create, update and delete Applications in a namespace, apply the
+`kubeapps-applications-write` ClusterRole in the desired namespace and the
+`kubeapps-repositories-read` Role in the `kubeapps` namespace:
+
+```
+kubectl create -n default rolebinding example-kubeapps-applications-write --clusterrole=kubeapps-applications-write --serviceaccount default:example
+kubectl create -n kubeapps rolebinding example-kubeapps-repositories-read --role=kubeapps-repositories-read --serviceaccount default:example
+```
+
+### Functions
+
+#### Read access to Functions within a namespace
+
+In order to list and view Functions in a namespace, apply the
+`kubeapps-functions-read` ClusterRole in the desired namespace and the
+`kubeapps-kubeless-config-read` Role in the `kubeless` namespace:
+
+```
+kubectl create -n default rolebinding example-kubeapps-functions-read --clusterrole=kubeapps-functions-read --serviceaccount default:example
+kubectl create -n kubeless rolebinding example-kubeapps-kubeless-config-read --role=kubeapps-kubeless-config-read --serviceaccount default:example
+```
+
+#### Write access to Functions within a namespace
+
+In order to create, update and delete Functions in a namespace, apply the
+`kubeapps-functions-write` ClusterRole in the desired namespace.
+
+```
+kubectl create -n default rolebinding example-kubeapps-functions-write --clusterrole=kubeapps-functions-write --serviceaccount default:example
+```
+
+### Service Catalog, Service Instances and Bindings
+
+#### Read access to Service Instances and Bindings within a namespaces
+
+Service Brokers, Classes and Plans in the Service Catalog are cluster-scoped
+resources, but Service Instances and Bindings can be restricted to a namespace.
+Kubeapps defines two roles (`kubeapps-service-catalog-browse` and
+`kubeapps-service-catalog-read`) to separate the roles required to view Service
+Instances and Bindings so that they can be applied to desired namespaces.
+
+In order to list and view Service Instances in a namespace, apply the
+`kubeapps-service-catalog-browse` ClusterRole in all namespaces and the
+`kubeapps-service-catalog-read` in the desired namespace.
+
+```
+kubectl create clusterrolebinding example-kubeapps-service-catalog-browse --clusterrole=kubeapps-service-catalog-browse --serviceaccount default:example
+kubectl create -n default rolebinding example-kubeapps-service-catalog-read --clusterrole=kubeapps-service-catalog-read --serviceaccount default:example
+```
+
+#### Write access to Service Instances and Bindings within a namespace
+
+In order to create and delete Service Instances and Bindings in a namespace,
+apply the `kubeapps-service-catalog-write` ClusterRole in the desired namespace.
+
+```
+kubectl create -n default rolebinding example-kubeapps-service-catalog-write --clusterrole=kubeapps-service-catalog-write --serviceaccount default:example
+```
+
+#### Admin access to configure Service Brokers
+
+In order to resync Service Brokers from the Service Brokers Configuration page,
+apply the `kubeapps-service-catalog-admin` ClusterRole in all namespaces.
+
+```
+kubectl create clusterrolebinding example-kubeapps-service-catalog-admin --clusterrole=kubeapps-service-catalog-admin --serviceaccount default:example
+```
+
+### App Repositories
+
+#### Read access to App Repositories
+
+In order to list the configured App Repositories in Kubeapps, apply the
+`kubeapps-repositories-read` Role in the kubeapps namespace.
+
+```
+kubectl create -n kubeapps rolebinding example-kubeapps-repositories-read --role=kubeapps-repositories-read --serviceaccount default:example
+```
+
+#### Write access to App Repositories
+
+In order to create and refresh App Repositories in Kubeapps, apply the
+`kubeapps-repositories-write` Role in the kubeapps namespace.
+
+```
+kubectl create -n kubeapps rolebinding example-kubeapps-repositories-write --role=kubeapps-repositories-write --serviceaccount default:example
+```
+
+### Assigning roles across multiple namespaces
+
+To give permissions in multiple namespaces, simply create the same RoleBindings
+in each namespace you want to configure access for. For example, to give the
+"example" user permissions to manage Applications in the "example" namespace:
+
+```
+kubectl create -n example rolebinding example-kubeapps-applications-write --clusterrole=kubeapps-applications-read --serviceaccount default:example
+kubectl create -n example rolebinding example-kubeapps-applications-write --clusterrole=kubeapps-applications-write --serviceaccount default:example
+```
+
+Note that there's no need to recreate the RoleBinding in the kubeapps namespace
+that is also needed, since that has already been created.
+
+If you want to give access for every namespace, simply create a
+ClusterRoleBinding instead of a RoleBinding. For example, to give the "example" user permissions to manage Applications in _any_ namespace:
+
+```
+kubectl create clusterrolebinding example-kubeapps-applications-write --clusterrole=kubeapps-applications-read --serviceaccount default:example
+kubectl create clusterrolebinding example-kubeapps-applications-write --clusterrole=kubeapps-applications-write --serviceaccount default:example
+```
+
+## RBAC rules required by Kubeapps
+
+An up-to-date list of RBAC rules Kubeapps requires can be found [here](/manifests/user-roles.jsonnet).
+
+## Using a cluster-admin user (not recommended)
+
+A simpler way to configure access for Kubeapps would be to give the user
+cluster-admin access (effectively disabling RBAC). This is not recommended, but
+useful for quick demonstrations or evaluations.
+
+```
+kubectl create serviceaccount kubeapps-operator
+kubectl create clusterrolebinding kubeapps-operator --clusterrole=cluster-admin --serviceaccount=default:kubeapps-operator
+```

docs/getting-started.md

@@ -43,7 +43,19 @@ To remove Kubeapps from your cluster, run this command:
 kubeapps down
 ```
 
-## Step 2: Start the Kubeapps Dashboard
+## Step 2: Create a Kubernetes API token
+
+Access to the dashboard requires a Kubernetes API token to authenticate with the Kubernetes API server.
+
+```
+kubectl create serviceaccount kubeapps-operator
+kubectl create clusterrolebinding kubeapps-operator --clusterrole=cluster-admin --serviceaccount=default:kubeapps-operator
+kubectl get secret $(kubectl get serviceaccount kubeapps-operator -o jsonpath='{.secrets[].name}') -o jsonpath='{.data.token}' | base64 --decode
+```
+
+NOTE: It's not recommended to create `cluster-admin` users for Kubeapps. Please refer to the [Access Control](docs/access-control.md) documentation to configure fine-grained access control for users.
+
+## Step 3: Start the Kubeapps Dashboard
 
 Once Kubeapps is installed, securely access the Kubeapps Dashboard from your system by running:
 
@@ -53,9 +65,13 @@ kubeapps dashboard
 
 This will start an HTTP proxy for secure access to the Kubeapps Dashboard and launch your default browser to access it. Here's what you should see:
 
+![Dashboard login page](../img/dashboard-login.png)
+
+Paste the token generated in the previous step to authenticate and access the Kubeapps dashboard for Kubernetes.
+
 ![Dashboard main page](../img/dashboard-home.png)
 
-## Step 3: Deploy WordPress
+## Step 4: Deploy WordPress
 
 Once you have the Kubeapps Dashboard up and running, you can start deploying applications into your cluster.
 

manifests/kubeapps.jsonnet

@@ -58,4 +58,14 @@ local labelifyEach(src) = {
     namespace:: $.namespace,
   },
   mongodb: labelifyEach($.mongodb_),
+
+  userRoles_:: (import "user-roles.jsonnet") {
+    namespace:: $.namespace,
+  },
+  userRoles: $.userRoles_ {
+    applications: labelifyEach($.userRoles_.applications),
+    functions: labelifyEach($.userRoles_.functions),
+    serviceCatalog: labelifyEach($.userRoles_.serviceCatalog),
+    repositories: labelifyEach($.userRoles_.repositories),
+  },
 }