I have a secret which contains very sensitive information.
I want to make sure that this secret can only be accessed by a certain service account and nobody else.
Using RBAC, I can tell which user can access which resources. But is there some way where I can tell that this secret can only be accessed by this user?
as far as i know , There is no straight forward way to get that info (might require write a script to that iterates through rolebindings & clusterrolebindings).
Recently found a plugin called kubectl who-can on kubectl-who-can that fetches those kind details with one command.
It is possible to get it done with Validating webhook where the API request fields are parsed and checked for matching users.
OPA can be used to do some heavy lifting.
Related
When managing entities semantically connected with Kubernetes, it makes sense to let Kubernetes manage them. Kubernetes manages ServiceAccount as a resource kind, but does not have similar kinds for human users or groups.
I'm wondering what is the design decision behind this. I know that ServiceAccount gets a token generated on creation that is used for further access, and for accessing a cluster as a human user, you need a config file with a public key signed with Kubernetes's CA.
It seems inconsistent, why not create similar resource kinds, say, HumanAccount or Account and supply a public key on creation (public key is kind of safe to store even in plain test in a yaml manifest), so that Kubernetes signs it and from that point on, accepts connections from the user?
I know that Certificate Signing Requests need to be approved by the administrator. Maybe that is the reason?
Any hints or insights appreciated!
There actually are User entities in RBAC, but kubernetes delegates the instantiation of those to either the CN field of mTLS authentication, or the sub claim of OIDC, or in a very customized situation one can provide that via HTTP headers
I'm studying Kubernetes now, and have a question about Kubernetes Users. I learned how to create Users and how to limit access by Role, but when should I use it? For example, if a malicious user (not a k8s user, but an operating user) penetrates the k8s server, they can switch the administrator easily (if they can see .kube/config). In addition to that, if a user switches his or her user account and forgets to switch back, then another person who enters next can also use the first user's account. I doubt if I misunderstand the usage of k8s Users, but there seems to be no documents about why k8s prepared it. I assume that Users are only used for doing something from within pods, but if so, what's the difference between Users and Service Accounts?
Kubernetes has a very loose idea of a user. It knows that authentication is a thing, and that the output of that is a name and maybe some groups and tags. But really all it does it hand that info off to the authorization plugins to decide if a given request is allowed or not. ServiceAccounts are a specific object type because they generate you a JWT signed by the cluster, but there isn't a specific User type, that only exists within the context of your authentication plugin(s).
I want to be able to give certain users limited access to the cluster. The admin user is in the kube config but i want to give access to individual users like "bob" but only to just a certain namespace etc. Is the possible without using RBAC?
you will need to use ABAC authorization mode: https://kubernetes.io/docs/admin/authorization/abac/
My task is to implement a resource server(RS) for IdentityServer4(IS4). The RS should fetch data from a database and send the necessary information as a json object back to the caller (client). This is needed because we have to return complex objects.
I already setup IS4 succesfully and its already running in Docker for testing purpose. I also setup the needed database.
My understanding of the flow would be, the user requests data from the RS sending the access-token, the RS then validates the token, checking if the caller is allowed to access the api using the IS4, if everything is okay the RS returns the data to the caller.
My problem is, as I'm new to this subject, how would I implement a RS? Do I create an API which is added as a scope to the user? Or is there a RS already implemented in IS4?
So yes you'll need to write your own API to serve your own resources, IdentityServer will only manage your identities for you (as well as handling external logins if that's what you need). I'd recommend going to the IdentityServer docs and working through the quick starts in order as shown below:
This will give you a good start but you'll then need to go away and research APIs more generally, there's a tonne of good info online about building (RESTful) APIs. You may find it useful to sign up to something like PluralSight and work through a couple of their courses, they're often very good.
One other thing to bear in mind is that IdentityServer is for identity, in other words Authentication and not specifically for Authorisation so you may need to add something for this. You can of course use a users identity for authorisation purposes but in most cases you'll probably need to augment the info you store about their identity to authorise them for access. See this link for more info around this topic.
The Kubernetes Dashboard allows users to see all secrets, including their raw values with just a couple clicks. These secrets will likely contain very sensitive data, such as production database passwords and private keys.
How do you limit users of the Dashboard, so that they can't see the sensitive data?
This is a known issue and it is simply not officially supported at the moment - the Dashboard is a super-user level administration tool. This should not be the case forever, but more help is needed to get it there.
There are some workarounds discussed in that issue thread that work currently. Here are some notable quirks around them to be aware of beforehand:
Should the dashboard be under a dashboard user, and limited by that? If so, like Anirudh suggested you can neuter parts of the Dashboard and it will work fine and get 403s if they access the Secrets panel.
Should the dashboard be under a logged in user, and be limited to what that user can see? This means that kubectl proxy will be necessary without some browser plugin or MITM proxy to attach the needed auth to dashboard server calls but it is possible.