For maximum security nine controls user access and authentication to your cluster. If you wish to add new user you must request this from firstname.lastname@example.org.
Nine Managed GKE offers different roles for user accounts, which need to be specified when ordering a new user.
These roles are mostly related to GKE, although they also influence what a user can see on Runway, which is explained later.
The following roles exist:
|viewer||Can view all contents of all namespaces, except secrets|
|user||Can create and delete owned namespaces, but does not have access to any other namespace. Can view secrets in owned namespaces|
|admin||Has full access to all namespaces|
Further, one may combine the
user role, which would result in a user that can view all namespaces and their contents, and can create own namespaces, where the user has full access to.
Granular access to namespaces
By default, the user that creates a namespace will also be Admin in it. Further, all users with the
admin role will have full access, and users with the
viewer role read-only access to that namespace too.
It is also possible to give an otherwise unprivileged user (with
user permissions) access to a namespace. This is possible by binding the user to a specific Kubernetes role. Every GKE cluster comes with the following predefined cluster roles which can be used in namespaces:
The following table lists the differences between those cluster roles when used in namespaced rolebindings:
|cluster role name||permissions when used in rolebinding|
|cluster-admin||This role gives full control over every resource in the rolebinding’s namespace, including the namespace itself.|
|admin||Allows admin access, intended to be granted within a namespace. It allows read/write access to most resources in a namespace, including the ability to create roles and rolebindings within the namespace. It does not allow write access to resource quota or to the namespace itself|
|edit||Allows read/write access to most objects in a namespace. It does not allow viewing or modifying roles or rolebindings.|
|view||Allows read-only access to see most objects in a namespace. It does not allow viewing roles or rolebindings. It does not allow viewing secrets, since those are escalating.|
To assign one of the predefined cluster roles to users in namespaces, the
kubectl application can be used. Here are some examples:
# creating a namespace admin with full privileges kubectl create rolebinding custom-admins-full-privileges --clusterrole=cluster-admin --user=<name>@ninegcp.ch [--user ...] --namespace=<your namespace> # creating a normal namespace admin kubectl create rolebinding custom-admins --clusterrole=admin --user=<name>@ninegcp.ch [--user ...] --namespace=<your namespace> # granting normal edit permissions kubectl create rolebinding custom-editors --clusterrole=edit --user=<name>@ninegcp.ch [--user ...] --namespace=<your namespace> # granting view only permissions kubectl create rolebinding custom-viewers --clusterrole=view --user=<name>@ninegcp.ch [--user ...] --namespace=<your namespace>
To edit the created rolebindings later on the
kubectl edit rolebinding <rolebinding name> -n <your namespace> command can be used.
Runway lists Service Accounts, their credentials, and connection secrets to CloudSQL instances, for example. Because these service accounts may have higher privileges than a user’s account, only users with the
admin role can view those secrets on Runway.
However, if you need an account that should not be admin in a GKE project, but should still be able to download the Service Account credentials or read CloudSQL connection credentials, you can also order a user plus the additional permission
Please keep in mind that this will potentially give users access to higher-privileged service accounts, which is a form of privilege escalation.
If you need a new password for your nine Managed GKE account, please contact support at email@example.com. Please be aware that you have to be registered as a technical contact in our system.