Keycloak is an enterprise-ready, open source identity access management (IAM) solution that's scalable, extensible, and robust. And it really doesn't need all that much care and feeding to launch a simple implementation.

This article will introduce you to the technology and the ways it can integrate best-practice authentication into your infrastructure.

Note on Hitachi Contributions to Keycloak:

Takashi Norimatsu works for Hitachi and has been the official maintainer of Keycloak since late 2021. Hitachi has been actively contributing to Keycloak since at least 2018.

Hitachi appears to be doing more strategically with open source in general and Keycloak in particular. I believe strong, continued corporate support as part of an open source project is a positive sign, but at the very least, you should be aware of the corporate support for Keycloak during your assessment.

Getting Started with Keycloak

I'll begin with a brief "quick start". As you can see from this screenshot, Keycloak will run happily on multiple platforms. And their product documentation is excellent.

But here's some very simple one-command Docker syntax that will create a fully-functioning live Keycloak instance on your local machine:

docker run -p 8080:8080 \
     -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
     -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.0.7 start-dev

That's it. After a minute or two, you can open the administration interface on your browser using the appropriate variation of:

localhost:8080

Based on the Docker command defaults, you'll log in using admin and admin. Spend a few minutes digging into the environment to get a feel for the tools that are available.

What Keycloak Offers

Ok. So why do you need Keycloak? Because it supports all the functionality demanded by modern deployments. That'll include Single Sign-On (SSO) to allow seamless authentication across multiple applications and services, OAuth2, OpenID Connect, SAML protocol compliance, and federated identities using existing LDAP or Active Directory setups or through social media logins like Google.

Keycloak incorporates the use of Multi-factor Authentication (MFA), built-in token revocation and expiration mechanisms, fine-grained permission management through Role-based Access Control (RBAC), and end-to-end encryption for sensitive communications. GDPR, HIPAA, and PCI DSS compliance are all possible.

Keycloak comes with a RESTful API for scripted and programmatic interactions. That will encourage task automation to further optimize your authentication processes. And your developers can build their own custom plugins to fill any usability gaps you encounter.

The Business Case for Keycloak

Because Keycloak is open source, there'll be no license fees to worry about. But open source gives you a lot more than just "cheap".

Keycloak cuts out vendor lock-in, allowing you to work with any platform or cloud provider – or move between them whenever necessary. It can also reduce overall operational costs through its simplified deployments (how much time did it take you to get that Docker image up and running?), automated updates, and no limits or cost penalties for even millions of monthly API calls or active users.

Having out-of-the-box (and free) access to the full feature set (including RBAC and MFA) also simplifies planning and execution. There's nothing "more" efficient than having to wait a week to access paywalled functionality until you get a response to your request for more project funding. All Keycloak features are just a click away.

This radar chart illustrates the feature and functionality differences between Keycloak and its major commercial peers.

What to Consider

As much as Keycloak has to offer, it won't be the ideal choice for every use-case. And there are issues about which you should be aware up front.

For instance, while getting started may be easy, fully configuring, say, clustering and high availability for Keycloak can be complex for teams without experience in identity management. Managing latency issues for very large deployments can be challenging.

And while the documentation is generally excellent, it may not fully address specific complexities or edge-case scenarios. Similarly, there's no resource within the Keycloak community that offers guaranteed support. Although there are excellent third-party providers out there.

It's possible that, because you're not working with a commercial product, demonstrating regulatory compliance could be a bit more involved. You may also need to adapt your logging functionality to comply with various audit trail requirements.

Finally, customizable environments risk introducing destabilizing complexity. The further off the beaten trail your plugins and API implementations wander, the greater the odds that something will eventually break – especially around version upgrades.

Your Next Steps

It's always helpful to explore the journeys other people took with a new technology.

So this page includes information on a fascinating case study involving a Japanese bank that was looking for an API solution and decided on Keycloak because of its high level API security features. Yuichi Nakamura’s presentation at the OpenShift Commons event in 2023 gives details how the bank successfully used Keycloak to secure their APIs. Nakamura, Hitachi Chief OSS Strategist, has recently been appointed as Head of Hitachi Open Source Program Office (OSPO).

And this is an account of a university that implemented Kerberos Single Sign-On (SSO) for FreeIPA and configured Keycloak to connect with FreeIPA. The university successfully achieved user authentication from Keycloak by leveraging the SSSD option under “user federation” instead of relying on Kerberos or LDAP.

I’m no stranger to Keycloak myself, having taught a Getting Started with Keycloak course on Pluralsight. For beginners, this may be a good place to start. A 10 day free trial is available.

The two keywords here are “who” and “permissions”. “Who” refers to a specific identity, which can be a user, group or role. “permissions” refer to the policies that are attached to an identity. These permissions either allow or deny access to a resource.

IAM is the AWS way of authenticating and authorising identities. Authentication is not, however, the same as authorisation. Authentication is concerned with the “who” while authorisation is concerned with the “permissions”.

The Difference Between Authentication and Authorisation

Authentication is when an identity proves it is what/who it says it is. Authorisation, on the other hand, is proving that you have the permissions to access a resource.

To fully understand the difference, consider the following analogy. You need to be both authenticated and authorised in order to board a flight. Authentication is done with your passport or ID, where it is checked to ensure that the photo in your passport matches your face. This proves that you are who you say you are.

After you have been authenticated, you need to prove that you have the permission to take a specific flight. This is done with your boarding pass.

Both authentication and authorisation need to be carried out before you can board a flight. Similarly, both need to be carried out before you can access AWS resources.

You can read more about authorisation vs authentication here.

Authentication & authorisation are not the same

IAM users, groups, and roles are concerned with authentication – that is, proving that you are who you say you are. They are like passports that get you through security in an airport.

Without a boarding pass however, you cannot board a plane. The IAM policy is like a boarding pass, in that it grants or denies access to specific resources.

What are IAM Users?

This is any identity (humans or an application) that requires long term access to AWS resources. These entities make requests to IAM to get authenticated before any interaction with AWS resources is allowed the happen.

Authentication is done using a username/password combination for humans accessing AWS through the console, or through access keys for an application or a human accessing AWS through the command line interface.

What are IAM Groups?

IAM users can be placed in an IAM group. IAM groups makes it easier to organise a large number IAM users and apply permissions on a group level instead of an individual level. This is because the latter does not scale for a large number of users.

Imagine you have a team that consists of developers, architects, admin staff, DevOps engineers, live support and testers. Each of these teams has 10 people, for a total of 60 people.

Instead of setting permission policies for 60 people individually, you can put IAM users into their respective groups and apply permissions on a group level. This makes it easier to organise permissions and also easier to scale as your team grows.

IAM groups can be created for separate teams

There are no login credentials for IAM groups. Also, a user can belong to multiple groups, so for example, an IAM user that is in the DevOps group can also be in the live support group. This maps neatly to the real world where a DevOps engineer can also be in live support.

What are IAM Roles?

IAM roles are used to grant temporary access to multiple identities. These identities could be humans external to AWS accessing your services, IAM users, or applications.

These identities assume the role temporarily, and any permission policies attached to the role are by proxy applied to the identity assuming that role.

IAM roles are important because AWS has hard limits on the number of IAM users (currently 5000).

Trust policies vs permission policies

IAM policies that are attached to roles come in two flavours – trust policy and permission policy.

The trust policy controls which identity (for example IAM users, AWS resources like EC2 instances, anonymous entities) can assume that role. Once a role is assumed by an identity, AWS issues it Temporary Security Credentials.

You can think of the trust policy as how AWS authenticates an IAM role to ensure that only the identity that is allowed to assume the role can assume the role – that is, that an identity has proved that it is who/what it says it is.

But there is a catch. With trust policies, this authentication only works for a period of time. Once that time has elapsed, the identity needs to re-authenticate and get new Temporary Security Credentials.

The permission policy is relatively straightforward: it defines the permissions that the role has, which, by proxy, defines the permissions that the identity assuming that role will have.

IAM roles are a relatively difficult concept to grasp, so if you don’t quite understand it yet, please read on and it will become clearer.

How IAM Policies Work

IAM Policies are attached to identities, so users, groups, or roles. IAM policies can also be attached to some AWS resources. These types of policies are called resource based policies.

IAM policies are JSON documents, consisting of one or more statements that grant or deny access to AWS resources.

The IAM policy below shows how permissions are granted to an identity to read and write from an S3 bucket.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListObjectsInBucket",
            "Effect": "Allow",
            "Action": ["s3:ListBucket"],
            "Resource": ["arn:aws:s3:::bucket-name"]
        },
        {
            "Sid": "AllObjectActions",
            "Effect": "Allow",
            "Action": "s3:*Object",
            "Resource": ["arn:aws:s3:::bucket-name/*"]
        }
    ]
}

• Sid stands for statement ID, an optional field that lets the reader quickly identify what a statement does.

• Effect can be either allow or deny

• Action refers to what action are you trying to perform. Format is service:operation.

• Resource refers to which resource are you interacting with. Typically you'll use ARN (Amazon Resource Name) which uniquely identify AWS resources.

By default, all requests are implicitly denied unless a policy explicitly has an “allow” as is the case in the example above.

This principle of least privilege ensures that an identity cannot use a resource unless they are explicitly granted the permission to do so.

Bringing it All Together – How IAM Works

Consider a pizza restaurant. It will have some full time employees – like chefs, waiters and cleaners. It may also have some part time chefs to help during peak demand on evenings and weekends. If the restaurant is any good, it will also have customers who can eat in and take out.

IAM restaurant analogy

To draw an analogy with AWS IAM, the full time employees are like IAM users. They require long term access to the restaurant’s resources as shown above. These users will all belong to different groups – the waiters, chef, and cleaners group (that is, all waiters, for example, will have the same job title of “waiter”).

IAM restaurant analogy

How are the restaurant’s employees authenticated? How do we know that they are who they say they are? Name badges with a picture will do the job. This can also show their title which is analogous to the IAM group that they belong to.

The permission policies that define what resources the restaurant’s employees can access are applied on the group level, since every waiter, chef and cleaner will have the same permissions. This may not be true in reality, as the head chef for example may have privileged access. But for simplicity, let's assume it is true.

How does the restaurant manager control who has access to what resources? Doors with locks will do just fine. Keys act as a policy as they control access to parts of the restaurant.

An identical set will be given to all waiters, since waiters will need the same level of access to the food/drink storage room, kitchen, and seating area.

The same logic will apply to the other full time employees, where the appropriate set of keys are handed out so that they can use the restaurant’s resources as needed.

Giving keys to the restaurant employees is analogous to attaching a policy to an IAM user or group. Without the keys, the employees cannot access parts of the restaurant.

Similarly in AWS, without policies that explicitly allow an action, requests cannot be made to AWS resources. The default state in both AWS and our restaurant analogy is an implicit deny when trying to access resources.

The part time employees, like a temporary chef for example, and the customers, don’t need long term access to resources but will need short term access, analogous to IAM roles.

The part time employees can only work during a short window – say during evenings on the weekend. Outside of this time, they don’t have permissions to use the restaurant’s resources.

This part time chef does not have to be the same person. It could be a different person every week, unlike the full time employees that have specific identities.

A part time chef will therefore assume the role of a chef and get a temporary badge that they keep for the duration of their shift. This is analogous to an entity assuming an IAM role that has a policy attached to it and getting Temporary Security Credentials that will expire after some time.

Again, the policy here is the set of keys that grant permission to parts of the restaurant while the Temporary Security Credential is the temporary badge used to authenticate the chef.

Similarly, the customers are analogous to IAM roles for two reasons. First, they only require temporary access to the restaurant. Second, and perhaps more importantly, a successful restaurant will have tens of thousands to hundreds of thousands of unique customers over its lifetime.

Having a large number of unidentified entities is a perfect use case for IAM roles. Recall that with AWS, there is a hard limit of 5000 for the number of IAM users you can have. If there is a use case where the number of IAM users required will exceed this 5000 limit, using IAM roles is your only option around this.

Just like how IAM roles are assumed, the customer first needs to order something to prove that they are a customer and can assume the role of a customer.

After the customer role is assumed, the permissions policy attached to the customer role is then applied to the customer as well. Customers have permissions to only use some resources like the seating area and the toilet.

To keep the analogy realistic, access to the toilet is controlled by entering a passcode which changes every day, thus ensuring that the access is temporary. This passcode is analogous to the policy attached to the customer role that grants temporary access to the toilet.

Example Use Case of IAM Roles

Consider the following very simple architecture: an EC2 instance running an application that needs full access to an S3 bucket.

How would you give the EC2 instance the permission to read and write objects from an S3 bucket? This is explained in the diagram below:

Attaching a policy to an IAM role and letting an EC2 instance assume that role

1. Create an IAM role for your EC2 instance

2. Attach an IAM policy to the role that gives full access to the S3 bucket

3. Let the EC2 instance assume the role

The IAM policy for full S3 access mentioned in step #2 is:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "s3-object-lambda:*"
            ],
            "Resource": "*"
        }
    ]
}

You can now read from and write to the S3 bucket. Notice that in the policy above, it doesn’t specify any ARN, but just says “*” for the resource. This means all S3 buckets. If that is what you want, then this policy is fine. But if you want to specify a single bucket, then you need to give the bucket ARN.

Wrapping Up

Understanding IAM and the difference between users, roles, groups and how policies work gives you a strong foundation on which you can architect and build secure solutions with AWS.

Thank you for reading!

IAM, or Identity and Access Management, is one of the most common terms you'll hear in cloud-native environments.

But what does it do? And if you're already familiar with IAM, how long did it take you to fully understand it?

I will explain the main concepts behind this massive family of software, with you, the busy engineer, in mind.

The fundamentals described here are vendor agnostic, though most of my experience is with AWS's implementation.

What Is IAM?

IAM is a complex system of entities (humans, applications, and so on) that request access to a system. It is also a hierarchical set of rules to grant or deny requested access.

Before we go any further, here are the main terms you'll encounter:

• Resource: Anything worth protecting. A storage service, virtual machine, etc.
• Policy: A set of rules that dictate who can and can't do something on a single resource or group of resources.
• Action: Anything someone can do inside the cloud environment. For example, creating a virtual machine.
• User: Well... A user :)
• Group: A group of users with the same permissions applied.
• Principal: A user or an application requesting access.
• Role: A set of powers assigned to a principal, usually for a limited amount of time.

Why IAM Is Useful

IAM is mainly used for authentication, authorization, granular access, and governance.

Let's see what those all mean:

• Authentication: The act over verifying who you are.
• Authorization: The act of identifiying if someone can perform the action they are requesting. This is usually combined with authentication, but not always.
• Granular access: Permissions that control each action that can happen on a resource. For example, a user might have permission to see firewall rules, but doesn't have permission to change them. This is implemented with Role-Based Access Control.
• Governance: The actions you take to know what is happening in your environment, mostly for reasons of budget, compliance, and proper access scope.

If you're a company of 1-3 people, then setting up a full-blown IAM solution is probably overkill. Buf if your team is larger than that, or you're planning to scale up, then you should start considering it.

Common Problems You Don't Use IAM

I believe you can see the benefits of an IAM solution.

Now let's take a look at some common problems organizations face in the absence of it.

It's Hard to Audit and Administer Access

Have you heard of cases where an employee had more access than they should? And additionally, no one knew?

This can be prevented with a properly set-up IAM solution.

Setting Up Accounts for New Hires Is a Pain

With an IAM solution in place, this would just be a matter of a few clicks. Namely, set up the users and add them to the IAM groups their teams use. That's it.

But without an IAM solution? You would need to set all the permissions for each account manually.

You might have a reference user to copy from, but does each new account need all the permissions the reference user has? Do you have special handling for user accounts that are less than 6 months old? Does the reference user have superuser permissions that should not be accidentally assigned to a new hire's account?

Offboarding People Is Time Consuming

Here you'll have similar problems to the new hire case above. But when a collegue is leaving, you'll need to change the password to all the accounts they potentially used.

This can turn ugly very fast, not to mention the side effects this has on other team memebers.

And you would have to do this for every script, application, and other resource whenever there's an offboarding. What if you have a team change 2-3 times per month? You and your team would have a hard time being productive.

Simple Things Require Human Intervention

Without an IAM solution, tasks like resetting a password or re-enabling an account that was locked need to be done manually.

Top-tier IAM solutions have a way to resolve such issues fast without much hassle.

Best Practices

If you've decided to set up IAM, here are some best practices. This is far from a full list, and is based on my personal experience. But I've seen these practices on more than one team, so they should work for you as well.

Never Grant Full Access... EVER

In a real-world scenario, you wouldn't want every user to have unlimited access to an account. Ideally, no one should full access to anything (apart from the account owner).

For example, if an employee's responsibility is to monitor logs, they should have read access only to that tool. They should not be able to restart a service, or view billing information.

Prefer Groups to Multiple Users

It's better to use groups instead of multiple users when you have a choice. Groups make administration exponentially easier.

For example, if a new person joins your organization as a developer, they can be added to an IAM group for developers. That new person will then inherit all the powers of that IAM group.

The alternative, creating a user for each group (reader_susan, admin_susan) is considered obsolete.

Prefer Roles on Existing Users to Creating a New User

When given the option, prefer assigning a role to an existing user rather than creating a new user.

For example, don't create an admin user and share the password between 10 people. Create an admin role and assign it to whoever needs it for a limited amount of time.

Audit Permissions Frequently

It is easy to make mistakes or perform malicious actions. At the very least, a company should audit permissions regularly, and ensure that only the proper people have the minimum level of access necessary for their roles.

You could also send an email to a certain team when a suspicious action happens. For example, assigning an admin role to a new hire.

Set Up Boundaries Beforehand

If an IAM solution allows for it, add boundaries to your ecosystem.

According to Amazon's documentation:

A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

(I know, I know — I promised to be vendor-agnostic 🙂)

In layman's terms, you can define the "maximum" permissions that can be assigned to anyone.

For example, a user will at most be able to view the logs from the relevant tool and restart a service. If someone attempts to get a role to create a new virtual machine they will be disallowed.

Conclusion

Thank you for reading this far. I hoped you enjoyed this introduction to IAM.

If you have any questions, please reach out to me on Twitter.

Introduction

Elastic Kubernetes Service (EKS) is the fully managed Kubernetes service from AWS. It is deeply integrated with many AWS services, such as AWS Identity and Access Management (IAM) (for authentication to the cluster), Amazon CloudWatch (for logging), Auto Scaling Groups (for scaling worker nodes), and Amazon Virtual Private Cloud (VPC) (for networking). Many companies trust Amazon EKS to run their containerized workloads.

EKS uses IAM to provide authentication to your Kubernetes cluster (via the aws eks get-token command, or the AWS IAM Authenticator for Kubernetes). For authorization it relies on native Kubernetes Role Based Access Control (RBAC). IAM is used for authentication to your EKS Cluster. And you can manage the permissions for interacting with your cluster’s Kubernetes API through the native Kubernetes RBAC system.

How to create an IAM User

Go to your AWS Console where you will find the IAM service listed under the “Security, Identity & Compliance” group. Inside the IAM dashboard click on the Users tab and click the “Add User” button.

Create a new user and allow the user programmatic access by clicking on the "Programmatic access" checkbox. You do not need any particular permission for your user to access EKS. You can go ahead without selecting any permission.

After the user is created, you will have access to the user's Access Key ID and Secret Access Key. You will be required to use these keys in the next step.

Configure the AWS CLI

Configuring your AWS CLI with a new user is as simple as running the aws configure command and providing the AWS Access Key ID and the AWS Secret Access Key. The Default region name and Default Output format are optional, though.

$ aws configure --profile eks-user
AWS Access Key ID [None]: AKIAI44QH8DHBEXAMPLE
AWS Secret Access Key [None]: je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
Default region name [None]: us-east-1
Default output format [None]: text

Once configured you can test to see if the user is properly configured using the aws sts get-caller-identity command:

$ aws sts get-caller-identity --profile eks-user

If the user is properly configured with the aws cli utility you should see a response like the one shown below:

{
    "UserId": "AIDAX7JPBEM4A6FTJRTMB",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/eks-user"
}

Creating a Role and RoleBinding for the user

With your IAM user properly configured, you can go ahead and create a role for the user. This snippet of code creates a role named eks-user-role with a modest list permission to the pods resource in your cluster.

kind: Role
metadata:
  name: eks-user-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list"]

Save the above snippet of code in a file and then apply the Role to your Kubernetes cluster:

$ kubectl apply -f role.yaml

With the role configured you need to create a corresponding RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: eks-user-role-binding
subjects:
- kind: User
  name: eks-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: eks-user-role
  apiGroup: rbac.authorization.k8s.io

Save the above snippet of code in a file and then apply the Role Binding to your Kubernetes cluster:

$ kubectl apply -f role-binding.yaml

Adding the user to the aws-auth configmap

If you want to grant additional AWS users or roles the ability to interact with your EKS cluster, you must add the users/roles to the aws-auth ConfigMap within Kubernetes in the kube-system namespace.

You can do this by either editing it using the kubectl edit command:

$ kubectl edit configmap aws-auth -n kube-system

Or by importing the aws-auth ConfigMap and applying the changes:

$ kubectl get configmap aws-auth -n kube-system -o yaml > aws-auth.yaml

Add the user under the mapUsers as an item in the aws-auth ConfigMap:

data:
  mapUsers: |
    - userarn: arn:aws:iam::123456789012:user/eks-user
      username: eks-user
      groups:
      - eks-role

If the user is properly configured you should be able to list pods in the Cluster:

$ kubectl get pods --as eks-user

The --as flag impersonates the request to Kubernetes as the given user. You can use this flag to test permissions for any given user.

Configuring permissions for the user

The role which you defined previously only had permission to list pods. The eks-user cannot access any other Kubernetes resources like Deployments, ConfigMaps, Events, Secrets, logs or even shell into a given pod.

In a real-world scenario, you will need to provide permissions to a user to access the required resources. The below snippet of code provides access to resources such as events, pods, deployments, configmaps and secrets.

rules:
- apiGroups: [""]
  resources: ["events"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods", "pods/log", "pods/exec"]
  verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["list", "get", "create", "update", "delete"]

Add the above permissions to the role.yaml file and apply the changes, using kubectl apply -f.

Test, test and test!

Now go ahead and test to see if the permissions have been properly applied to the eks-user. You can test the same using the above mentioned --as USERNAME flag or set the eks-user as the default profile for the aws cli.

$ export AWS_PROFILE=eks-user

Once configured you can test to see if the user is properly configured using the aws sts get-caller-identity command:

$ aws sts get-caller-identity

You should see a response like the following, indicating the user is properly configured with your aws cli utility:

{
    "UserId": "AIDAX7JPBEM4A6FTJRTMB",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/eks-user"
}

Test the permissions of the user with the below-mentioned commands.

$ kubectl get pods
$ kubectl get secrets
$ kubectl get configmaps
$ kubectl get deployments
$ kubectl logs <pod-name>
$ kubectl exec -it <pod-name> sh
$ kubectl create configmap my-cm --from-literal=db_username=<USERNAME> --from-literal=db_host=<HOSTNAME>
$ kubectl create secret generic my-secret --from-literal=db_password=<SOME_STRONG_PASSWORD>

Simply put, the eks-user user should be able to perform all the actions specified in the verbs array for pods, secrets, configmaps, deployments, and events. You can read more about it here Kubernetes Authorization Overview.

Can-I or Not

You can use auth can-i to check if you have permission to a resource. To see if you have the permission to get pods simply run:

$ kubectl auth can-i get pods

The answer will be a simple yes or no. Amazing, isn’t it?

Wanna check if you have cluster-admin permissions? Fire this:

$ kubectl auth can-i "*" "*"

Wrap up

EKS provides the Kubernetes control plane with the backend persistence layer. The Kubernetes API server and the master nodes are provisioned and scaled across various availability zones, resulting in high availability and eliminating a single point of failure. An AWS-managed Kubernetes cluster can withstand the loss of an availability zone.

Access and authorization controls are critical for any security system. Kubernetes provides us with an awesome robust RBAC permission mechanism.

Originally published at faizanbashir.me