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).
Related
I'm trying to improve my knowledge in GCP-GKE as a newbie and in the way to do that, I found out a little concept that I don't quite understand yet. In GKE, there is a Service Account called service-PROJECT_NUM#container-engine-robot.iam.gserviceaccount.com (where the PROJECT_NUM is the ID of our project) and after several hours googling, I couldn't find any article or definition about this stuff. So could you guys please explain to me
What is this Service Account ? How was it created (by who)?
What is this thing for? How important is it in GKE?
What happens if we delete it ? Could we re-created it manually ?
In fact, I found out that in GCP, we have some Service Account that have a "robot" suffix: ...robot.iam.gserviceaccount.com/ (like #gcf-admin-robot.iam.gserviceaccount.com/, #serverless-robot-prod.iam.gserviceaccount.com, etc). What could we say about this, please ?
If I misunderstand something, please, point it out for me, I really appreciate that.
Thank you guys !!!
Service Accounts aka "robots" contrast with user ("human") accounts and represent two forms of Google identity.
NOTE Robots was the original name for Service Accounts and is a more colorful description of the intent of these accounts, to run software.
(Google) User accounts include consumer (Gmail) e.g. you#gmail.com and you#employee.com (Workspace) accounts. User accounts are used by humans to interact with Google services and must be used (or a suitable delegate) to acccess user-owned content such as Workspace docs, sheets etc.
Software ("robots") generally should run as a Service Account not as a User account. In part, you can't easily run software using User accounts because the User OAuth flow is 3-legged and requires interacting with an OAuth Consent Screen to permit an app access to data.
There are two flavors of Service Account: Google-created|managed and User-created|managed. The difference is essentially the owner. If you create applications, generally you should create a Service Account for each app and run the app using its Service Account.
User-managed Service Accounts take the form {something}#{project}.iam.gserviceaccount.com where you get to define the value of {something} and the Google Project in which the Service Account is created (the project that owns the Service Account) is represented by {project} (actually the Project ID).
When Google provides app functionality, it also creates Service Accounts and often, Google "binds" these Service Accounts to your projects that use them in addition to defining the role that the Service Account has in your project.
Google-managed Service Accounts take the form {something}#{label}.iam.gserviceaccount.com. Unlike User-managed Service Accounts, Google uses more descriptive labels ({label}) to help explain the role of the Service Account.
NOTE With Google-managed Service Accounts {something} often includes the Project Number (not ID) of (your!) project for which the Google-managed account has been created.
You cannot delete Google-managed Service Accounts because you(r Google account) does not own the Service Account.
You can (but should not) delete the role binding between one of your projects and a Google-managed Service Account. It may be possible for you to revert (recreate) the binding but you may not have permission to do this.
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 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.
I have 2 users, one with less than 30 roles and one with 400 roles. When I login with the 30 role user, I can reach the redirect URL without issues. But when I log in with the 400 role user, the request to the redirect URL doesn't complete. If I reduce the number of roles in the 400 role user then it will work. So, is there a way to disable passing roles in the java access token or increase some limit somewhere that's causing the failure?
I would suggest to focus rather on roles reduction/optimization than forcing the transmission (raising limits) over the maximum number of roles inside tokens (or anywhere else).
Some interesting questions (among others) to start with:
Which protected resources am I going to serve?
What am I trying to protect? and what are the associated risks? (build a Threat Model)
How do resources are served by each application? and how are they distributed among my applications?
What kind of resources are they? How can I group them? Which sets are identifiable? or what are the relationships between them? What actions are possible against all sets of resources?
Who are the users of each application? How will they interact with my resources? Which flows are sensitive?
What roles can I define for all my resources?
Which role can apply to each application, resource type or set?
What kind of user groups can I create?
Do I need additional attributes or claims for each set of roles or users/groups?
I firmly believe that if you answer all these questions you will end up having a bunch of roles instead of hundreds. Think security by design and follow principle of least privilege.
Focus on your use case
Now as far as I understand, your blocking point is that you are assuming that each resource is unique, sensitive and requires its own permissions, and consequently a role definition. While it may be true in some cases, in most other cases it does not mean that you have to use the token roles/scopes/claims to secure your assets deep at the resource-level. I'll try to illustrate this sentence by an example.
RBAC and authorizations example for your use case
Let's assume that:
you have millions of sensitive resources to serve
each registered user of your application has access to a (different) set of these resources.
your resources are splitted into, say, 3 categories (e-books, videos, musics).
each resource can be downloaded, uploaded, deleted.
your application will meet unregistered users, registered users, contributors and administrators
registered users will always have read access to resources (not a single action will ever allow a modification)
contributors are particular registered users who can perform special actions including modification ('upload', 'edit')
contributors and administrators may have access to various administrative parts of the application
your application will evolve by serving additional categories of resources in the future and new actions will be available to users later (such as 'flag', 'edit' or 'share link').
Then first things first:
organize your resources accordingly by serving them behind categorized paths such as: .../myapp/res/ebooks, .../myapp/res/videos, .../myapp/res/musics
identify your resources via UUID such that a resource may look like: .../myapp/res/ebooks/duz7327abdhgsd95a
Now imagine that your business risks or at least the greatest risks you wish to avoid are:
unregistered users having gaining access or rights for any part of the application or resource
uncontrolled registration process (robots, spam, no mail verification, fake users, ...)
registered users gaining illegal privileges (unauthorized actions, access to other categories, illegal administrative rights)
discovery of available resources by any mean
You will note that I voluntarily didn't listed:
registered user having illegal access to certain resources. For example: maliciously pointed/provided by an existing user.
This is because it is not a high risk as you may hold contact information about registered users as well as log activity and actions, quota or requests throttling, and you may be able to ban them or start legal action against them. Your registration process is also assumed robust and secure. Nonetheless if its considered a critical risk you can address this with extra mechanisms (cf. suggestions at the end). But never will it result in adding extra roles, such as one per resource, as it does not fit in any security model.
That being said, finally, here are the roles and authorizations scheme you may come with:
SCOPE / AUDIENCE
MY_APP
ROLES
USER
CONTRIBUTOR
ADMINISTRATOR
CLAIMS / ATTRIBUTES
CATEGORIES
ACTIONS
--> POSSIBLE USER GROUPS
USERS
Roles: USER
Claims: CATEGORIES(variable), ACTIONS('download')
CONTRIBUTORS
Roles: USER, CONTRIBUTOR
Claims: CATERGORIES(variable), ACTIONS('download', 'upload', 'edit')
ADMINISTRATORS
Roles: USER, CONTRIBUTOR, ADMINISTRATOR
Claims: CATEGORIES(*), ACTIONS(*)
Following this model, assigning the correct group to each registered user will provide high-grade security by mitigating/controlling the main risks. As claims/attributes are defined in the token(s) (managed and signed by Keycloak) then you can trust this information in your application and serve your resources accordingly and safely. There is also no risk of illegal access or discovery of resources as you are using UUIDs, only registered users having had access once to a resource will know it and registration with appropriate category access will be needed for another user to access it (to only be able to read it basically). Of course you may store in a database the list of resources to which each user has access to, raising the overall security to a very high level.
However, if the latest is not enough you may also implement rolling UUIDs or temporary links for your resources when served to users. To go farther you may also define groups and masks for your categories, resources and actions.
In fine, in this example I made use exclusively of token claims to define roles (common claim), categories and actions (custom claims). In terms of security the authentication and identity will be the first-line security followed by roles then categories, actions and stored list of resources per user (db).
Other alternatives are obviously possible, its just an example. Still, I hope it helps!
To fix this problem you should start from defining client scope mappings for each of you applications (e.g. oidc clients). Main idea of this facility is that even if your user is super duper admin with all existing roles, all of his roles actually don't required for any particular application. For example client foo which defines following roles:
foo_user
foo_viewer
to perform its security logic need to know only whether currently logged user has foo_user or foo_viewer, but it doesn't care about has this user roles bar_user or bar_admin from application bar. So our goal is to make Keycloak return for any client access token with only valuable set of roles for this client. And roles scope mappings is you friend here. You can set for client foo scope like:
foo.foo_user
foo.foo_viewer
bar.bar_admin
and now even if logged user has role "bar.bar_admin" this will not go to access_token since client foo doesn't take this role into account. After applying some scope settings you can test them at 'Clients -> $CLIENT_OIDC_ID -> Client scopes tab -> Evaluate sub tab.
As for you case with 400 roles, i'm quite confident that none of your application requires all of 400 roles, so precise scope configuration for you apllications can drammatically reduce access token size.
But if i'm mistaken and you really have an application that rely on large amount of roles you should look into you runtime settings.
For example if you run keycloak behind reverse proxy like nginx large tokens may not fit in default HTTP parameters buffer size (afaik about 2-4kb) so you have to increase it via appropriate nginx configuration option. Another example is tomcat which has about 16kb as default HTTP header buffer, so if you send request with very large access token in Authorization header Tomcat may not handle this request properly.
We have a multi-tenant system with multiple different levels of access--sometimes even for the same user as they switch between multiple roles. We're beginning a discussion on moving over to a RESTful implementation of things. I'm just starting to get my feet wet with the whole REST thing.
So how do I go about limiting access to the correct records when they access a resource, particularly when taking caching into consideration? If user A access example.com/employees they would receive a different response than user B; user A may even receive a different response as he switches to a different role. To help facilitate caching, should the id of the role be somehow incorporated into the uri? Maybe something like example.com/employees/123 (which violates the rules of REST), or as some sort of subordinate resource like example.com/employees/role/123 (which seems silly, since role/### is going to be appended to URIs all over the place). I can help but think I'm missing something here.
edited to mention multi-tenancy
Having the user credentials act as an out of band resource identifier (ie. presenting different views on the same URL to different roles) will turn nasty down the road. Users and applications exchange URLs between them, things turn sour when that happens and the URL simply returns different content for different credentials.
I would say that each role has a different view of the world, therefore each role should access a different path to the service:
admins connect to example.com/admin/employees
users connect to example.com/users/employees
role foo probably connects to example.com/foo/employees
This way you separate the 'this role sees the world as such and such' part from the 'this view of the world is accessible to role foo' part. An admin can connect to example.com/users/employees and verify how an ordinary user sees the world, w/o the admin having to impersonate a lower privileged alias first.
You can also use the DNS part for same purpose: admin.example.com/employees vs. users.example.com/employees. This is specially viable for a related scenario, when the 'role' is not a security role but a multi-tenant namespace (ie. each service provisioned account gets its own 'view' of the service).