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?
Related
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.
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.
I have an application that is going to monitor and if necessary scale other resources. At the moment I am using the cluster-admin tokens for it to access the k8s api but I want to limit its access to just monitor and scale.
I know that I need to use Role and Rolebinding for this but I have two questions:
Can I use just one user and bind it to a role in different namespaces? I need to run multiple instances of my application in different namespaces on a cluster
Is there a way to create a new k8s user via yaml file and use that to bind the role?
At the end if I am using a wrong approach please let me know because I am somehow newbie in RBAC.
You seem to have the right approach.
Have a look at the documentation: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
From experience always leave resources that are linked inside the same namespace, one user with one clusterrole and rolebinding.
Still in the case of rolebinding, they are not namespaced so you should be able to bind one user by namespace to a single clusterrole. Never tested it myself so you will have to do some testing.
There is still the question of why not just create a single app, with a serviceaccount having access to all namespaces and so one app deployed in a namespace will be able to access all the resources it needs to managed in all the cluster?
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