updating readme to include GKE integration

README.md

@@ -13,6 +13,7 @@ brew install reactiveops/tap/rbac-lookup
 
 ## Usage
 
+In the simplest use case, rbac-lookup will return any matching user, service account, or group along with the roles it has been given.
 ```
 rbac-lookup rob
 
@@ -21,6 +22,8 @@ [email protected]           cluster-wide      ClusterRole/view
 [email protected]           nginx-ingress     ClusterRole/edit
 ```
 
+The wide output option includes the kind of subject (user, service account, or group), along with the source role binding.
+
 ```
 rbac-lookup rob -owide
 
@@ -29,17 +32,53 @@ User/[email protected]      cluster-wide      ClusterRole/view    ClusterRoleBindi
 User/[email protected]      nginx-ingress     ClusterRole/edit    RoleBinding/rob-edit
 ```
 
+With a more generic query, we can see that a variety of users and service accounts can be returned, as long as they match the query.
 ```
 rbac-lookup ro -owide
 
 SUBJECT                   SCOPE             ROLE                SOURCE
 User/[email protected]      cluster-wide      ClusterRole/view    ClusterRoleBinding/rob-cluster-view
 User/[email protected]      nginx-ingress     ClusterRole/edit    RoleBinding/rob-edit
-User/[email protected]     cluster-wide      ClusterRole/admin   ClusterRoleBinding/ross-admin
 User/[email protected]      web               ClusterRole/edit    RoleBinding/ron-edit
 ServiceAccount/rops       infra             ClusterRole/admin   RoleBinding/rops-admin
 ```
 
+Of course a query is an optional parameter for rbac-lookup. You could simply run `rbac-lookup` to get a full picture of authorization in your cluster, and then pipe that output to something like grep for your own more advanced filtering.
+```
+rbac-lookup | grep rob
+
+User/[email protected]      cluster-wide      ClusterRole/view    ClusterRoleBinding/rob-cluster-view
+User/[email protected]      nginx-ingress     ClusterRole/edit    RoleBinding/rob-edit
+```
+
+### GKE IAM Integration
+
+If you're connected to a GKE cluster, RBAC is only half the story here. Google Cloud IAM roles can grant cluster access. Cluster access is effectively determined by a union of IAM and RBAC roles. To see th relevant IAM roles along with RBAC roles, use the `--gke` flag.
+
+```
+rbac-lookup rob --gke
+
+SUBJECT              SCOPE             ROLE
+[email protected]      cluster-wide      ClusterRole/view
+[email protected]      nginx-ingress     ClusterRole/edit
+[email protected]      project-wide      IAM/gke-developer
+[email protected]      project-wide      IAM/viewer
+```
+
+Of course this GKE integration also supports wide output, in this case referencing the specific IAM roles that are assigned to a user.
+
+```
+rbac-lookup rob --gke -owide
+
+SUBJECT                   SCOPE             ROLE                SOURCE
+User/[email protected]      cluster-wide      ClusterRole/view    ClusterRoleBinding/rob-cluster-view
+User/[email protected]      nginx-ingress     ClusterRole/edit    RoleBinding/rob-edit
+User/[email protected]      project-wide      IAM/gke-developer   IAMRole/container.developer
+User/[email protected]      project-wide      IAM/gcp-viewer      IAMRole/viewer
+```
+
+At this point this integration only supports standard IAM roles, and is not advanced enough to include any custom roles. For a full list of supported roles and how they are mapped, view `lookup/gke_roles.go`.
+
 ### Kubernetes Configuration
 If a `KUBECONFIG` environment variable is specified, rbac-lookup will attempt to use the config at that path, otherwise it will default to `~/.kube/config`.