I'm a little confused about the default Service Account in new created Namespace in my Minikube.
Does it have any permissions? It seems not because I can't find any rolebinding or clusterrolebindung which references this SA
Then why is it created when it does not have a permission, or is there a use case around that?
and lastly, why are service accounts by default mount to pods?
Regards
ralph
The default service account doesn’t have enough permissions to retrieve the services running in the same namespace.
Kubernetes follows the convention of closed-to-open which means that by default no user or service account has any permissions.
To fulfill this request, we need to create a role binding associating the default service account with an appropriate role.This is similar to how we assign a viewer role to the service account that can give permission to list pods.
Pods have the default service account assigned even when you don’t ask for it. This is because every pod in the cluster needs to have one (and only one) service account assigned to it.
Refer Kubernetes namespace default service account for more information.
Related
in Kubernetes, I want to get all the bindings (role binding or clusterrolebinding) that belong to a service account. Is there a way to do this?
I have a very specific scenario I'm trying to solve for:
Using Kubernetes (single cluster)
Installing Vault on that cluster
sending GitLab containers to the same cluster.
I need to install Vault in such a way that:
Vault lives in it's own namespace (easy/solved)
Vault's service account (vault-auth) is available to all other namespaces (unsolved)
GitLab's default behavior is to put all apps/services into their own namespaces with the Project ID; EG: repo_name+project_id. It's predictable but the two options are:
When the app is in its own namespace it cannot access the Vault service account in the 'vault' Namespace. It requires you to create a vault service account in each application namespace; hot garbage, or...
Put ALL apps + Vault in the default namespace and applications can easily find the 'vault-auth' service account. Messy but totally works.
To use GitLab in the way it is intended (and I don't disagree) is to leave each app in it's own namespace. The question then becomes:
How would one create the Kubernetes Service Account for Vault (vault-auth) so that Vault the application is in it's own namespace but the service account itself is available to ALL namespaces?
Then, no matter the namespace that GitLab creates, the containers have equal access to the 'vault-auth' service account.
I am trying out the capability where 2 pods deployed to the same worker node in EKS are associated to different service accounts. Below are the steps
Each service account is associated to a different role one with access to SQS and other without access.
Used eksutil to associate OIDC provider with cluster and also created iamserviceaccount with service account in kubernetes and role with policy for accessing SQS attached (implicit annotation of service account with IAM role provided by eksctl create iamserviceaccount).
But when I try to start the pod which has service account tied to role with SQS access, I am getting access denied for SQS, however if I add SQS permissions to worker node instance role, its working fine.
Am I missing any steps and is my understanding correct?
So, there are a few things required to get IRSA to work:
There has to be an OIDC provider associated with the cluster, following the directions here.
The IAM role has to have a trust relationship with the OIDC provider, as defined in the AWS CLI example here.
The service account must be annotated with a matching eks.amazonaws.com/role-arn.
The pod must have the appropriate service account specified with a serviceAccountName in its spec, as per the API docs.
The SDK for the app needs to support the AssumeRoleWithWebIdentity API call. Weirdly, the aws-sdk-go-v2 SDK doesn't currently support it at all (the "old" aws-sdk-go does).
It's working with the node role because one of the requirements above isn't met, meaning the credential chain "falls through" to the underlying node role.
Is it possible to have multiple rolebindings on the same service account in k8s?
yes, you can have multiple role bindings for a specific service account.
say, you want to grant read only permissions to SA at cluster level, and read and write permissions at namespace level. in this case you will be creating one role binding at namespace level and another at cluster level
Let's say I set up a fresh Kubernetes cluster. I assume the both kube-system and default namespaces will get a service account named default? Which permissions does that service account have? Full read/write permissions?
I'm essentially asking this to understand best practises to give a custom Go controller write access to resources.
Service accounts have no inherent permissions. The permissions they have depend entirely on the authorization mode configured (--authorization-mode flag passed to the apiserver)
Defining RBAC roles is a good method for specifying the permissions required for a controller.
There are existing role definitions for in-tree controllers at https://github.com/kubernetes/kubernetes/tree/master/plugin/pkg/auth/authorizer/rbac/bootstrappolicy