Best practices for authz to Kubernetes cluster


#1

In an Enterprise, Spinnaker is configured with a service account connecting to the cluster with clusterrole permissions to core api groups. What is a recommended practice to provide visibility to a subset of namespaces based on user login to Spinnaker for pipeline creation?

  1. Create multiple accounts in the hal/clouddriver config with same K8s service account to connect to K8s, then restrict the namespaces for the corresponding Spinnaker account. When user logs in the authorization group will have permissions set using fiat to one Spinnaker account that has the relevant namespace restriction of K8s.

  2. K8s service account configured in Spinnaker supports impersonation. When a user logs in, Spinnaker will impersonate the user to retrieve namespaces, secrets and other information from K8s cluster.

  3. There is oAuth Scope parameter in the config file for K8s in Spinnaker. Not sure how this works, but guessing this can be used similar to option 1.

There could be other ways if one can generate kubeconfig for service accounts that have restricted permissions to certain namespaces and can be used by Spinnaker to operate on those namespaces.

Look forward to get an understanding on what is possible and recommended options for multiple groups deploying to K8s using Spinnaker.


#2

Can you elaborate on #2?

@dpeach can explain #3.

I would lean towards having multiple users like you have pointed out in #1, but granting each user’s service account only the permissions they need using RBAC in Kubernetes in addition to Fiat’s permissions in Spinnaker.


#3

Option 2 is when there is sso in an organization with Spinnaker and Kubernetes using the authentication from same provide like ldap. Spinnaker will be configured with service account that has impersonation capability when connecting to Kubernetes.

User login to Spinnaker will provide the username or impersonate user group information to Spinnaker. Then Spinnaker would connect to Kubernetes with service account, impersonate the logged in user to request for namespaces allowed, and then will operate with in the namespaces that the user has permission in the kubernetes cluster.

Spinnaker may not be operating in this mode as there is no documentation on it. However, did not want to assume that this is not present.


#4

The OAuth scopes (and service account) exist to allow authentication with a k8s cluster using an OAuth token.