Let us learn more about the error configmaps aws-auth already exists. With the support of our AWS support services at Bobcares, we can give you a complete solution for the error.
Configmaps aws-auth already exists: Error
When we utilize the Amazon Management Console with an AWS Identity and Access Management (IAM) user or role, we may encounter this error.
The issue indicates that the IAM user or role does not have the requisite RBAC permissions (from the Kubernetes website) to use the Kubernetes API. The AWS IAM user or role must map to aws-auth ConfigMap in the Amazon EKS cluster in order to see Kubernetes resources on the AWS Management Console.
When we construct an Amazon EKS cluster, we automatically assign system:masters rights to an IAM user or role in the cluster’s RBAC setup. This allows us to access Kubernetes resources via the Amazon EKS interface. It also allows us to change the aws-auth ConfigMap within Kubernetes and provide new Amazon users or roles access to the cluster.
There are two permission mechanisms in use. IAM is used by the Amazon Management Console. The Kubernetes RBAC system is used by the EKS cluster (from the Kubernetes website).
The aws-auth ConfigMap in the cluster connects IAM identities (users or roles) with cluster RBAC identities. The aws-auth ConfigMap therefore connects IAM identities with Kubernetes identities.
Solution for Error: configmaps aws-auth already exists
Requirements for error management
We have to collect the following information before we begin the error removal.
Non-admin user or role
If we are not a cluster admin IAM user or role and need visibility to the Amazon EKS interface, take these steps:
- Get the AWS Management Console user’s IAM Identity Amazon Resource Name (ARN). If the role is an IAM role, use the following ARN format:
It is critical to not use the following format:
- Provide the ARN to the cluster admin and request that we be added to the aws. -authentication ConfigMap.This s the first step in removing the configmaps aws-auth already exists error.
Cluster creator or cluster admin user or role
Assume we are the cluster creator or administrator, and then utilize the kubectl or eksctl tools to manage the aws-auth ConfigMap. This will eventually resolve the error configmaps aws-auth already exists.
Notice that the system:masters group is by default connected to the clusterrole cluster-admin. Under its PolicyRule, this clusterrole employs the wildcard (“*”) for Resources and Verbs. This implies that any user in the system:masters group has complete access to all Kubernetes resources in the cluster.
For further instructions on how cluster creators and cluster administrators can determine their admin status, see the Identify the cluster creator section.
Identify the IAM Identity ARN of the AWS Management Console user
Determine the IAM user or role we’re using to access the console. This may differ from the identity we use with the Amazon Command Line Interface (AWS CLI).
Check that the indicated IAM user or role has rights in the Amazon Management Console to see nodes and workloads for all clusters. Next, obtain the ARN of the IAM identity. To access the ARN, use one of the following methods.
- Use the AWS CLI
Assuming we have Amazon CLI access to the IAM user or role, execute the following command:
- Launch CloudShell
consider that we don’t have the access, in this case run the comm anf line given below:
The result is something like this:
"arn:aws:iam::111122223333:role/testrole"
-or-
"arn:aws:iam::111122223333:user/testuser"
Things to note
- If it’s an IAM role ARN, we must ensure that the format matches the ARN format obtained from the Prerequisites section.
- If the ARN contains assumed-role, we must obtain the ARN of the role. The assumed role
ARN arn:aws:sts::123456:assumed-role/MyRole/aadams
, for example, is connected with the role ARNarn:aws:sts::123456:role/MyRole
. This value may be checked in the IAM console.
Identify the cluster creator
Search for the CreateCluster API call in Amazon CloudTrail to discover the cluster creator or admin role with main rights to configure the cluster. Then, examine the API call’s userIdentity portion.
If we identify the name of the cluster creator in CloudTrail but it has been erased, we must establish a new IAM user or role with the same name. As it has the same ARN as the original cluster creator, this new IAM entity receives the same admin access to the cluster.
Add a new IAM user or role to the Kubernetes RBAC, using kubectl or eksctl
Before we use the kubectl or eksctl tools to change the aws-auth ConfigMap, we must first finish step 1. Next, to modify with kubectl, repeat steps 2-4.
-
Configure Amazon CLI to utilize the cluster creator IAM after identifying the cluster creator or admin.
Run the following command to ensure that Amazon CLI is properly setup with the IAM entity:
$ aws sts get-caller-identity
The ARN of the IAM user or role is returned in the output. As an example:
{
"UserId": "XXXXXXXXXXXXXXXXXXXXX",
"Account": "XXXXXXXXXXXX",
"Arn": "arn:aws:iam::XXXXXXXXXXXX:user/testuser"
}Note: If we encounter issues when performing the CLI commands, we must ensure that we are using the most latest version of Amazon CLI.
-
We need cluster access to alter the aws-auth ConfigMap with kubectl. Execute the kubectl command:
$ kubectl edit configmap aws-auth -n kube-system
The console displays the current configurationMap.
If we are unable to connect to the cluster, please update the kubeconfig file. Execute the file with an IAM identity that has cluster access. The identity that formed the cluster always has access to the cluster.
Change region code with the AWS Region code for the EKS cluster and my cluster with the name of the EKS cluster. Now proceed to the next steps to remove the configmaps aws-auth already exists error.
-
Run the following command as the cluster creator or admin to change the aws-auth ConfigMap in the text editor:
$ kubectl edit configmap aws-auth -n kube-system
-
set up an IAM user or role. To do this follow the command line given below:
-or-
Include the IAM role in mapRoles. As an example:
We must consider the following facts:
a: A superuser can use system:masters to execute any action on any resource. This is not recommended for production situations.
b: It is great practice to limit the number of permissions issued. Consider designing a position that only has access to a single namespace.
-
Using the eksctl tool, we can alter the aws-auth ConfigMap as follows:
Note: we have to change the Change the cluster Name with YOUR EKS cluster name, the region with the EKS cluster Region, and YOUR IAM ARN with the IAM role or use ARN.
Verify access to the Amazon EKS cluster
Verify access to the Amazon EKS cluster
This is the final step to remove the configmaps aws-auth already exists error. To verify follow the steps given below:
- Go to the Amazon EKS console.
- Choose Clusters from the Amazon EKS part of the navigation window.
- We must select the cluster.
- Look for issues in the Overview and Workloads tabs.
If we configure for a specific namespace, the Amazon EKS interface displays the following error message:
The error does not occur in this namespace.
[Need assistance with similar queries? We are here to help]
Conclusion
To sum up we have no we have now seen how to deal with the error configmaps aws-auth already exists. With the support of our AWS support services of Bobcares, we have gone through a complete note on how to remove the error.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
var google_conversion_label = "owonCMyG5nEQ0aD71QM";
0 Comments