Creates an access entry.
See https://www.paws-r-sdk.com/docs/eks_create_access_entry/ for full documentation.
eks_create_access_entry(
clusterName,
principalArn,
kubernetesGroups = NULL,
tags = NULL,
clientRequestToken = NULL,
username = NULL,
type = NULL
)
[required] The name of your cluster.
[required] The ARN of the IAM principal for the AccessEntry
. You can specify one
ARN for each access entry. You can't specify the same ARN in more than
one access entry. This value can't be changed after access entry
creation.
The valid principals differ depending on the type of the access entry in
the type
field. The only valid ARN is IAM roles for the types of
access entries for nodes:
. You can use every IAM principal type
for STANDARD
access entries. You can't use the STS session principal
type with access entries because this is a temporary principal for each
session and not a permanent identity that can be assigned permissions.
IAM best practices recommend using IAM roles with temporary credentials, rather than IAM users with long-term credentials.
The value for name
that you've specified for kind: Group
as a
subject
in a Kubernetes RoleBinding
or ClusterRoleBinding
object.
Amazon EKS doesn't confirm that the value for name
exists in any
bindings on your cluster. You can specify one or more names.
Kubernetes authorizes the principalArn
of the access entry to access
any cluster objects that you've specified in a Kubernetes Role
or
ClusterRole
object that is also specified in a binding's roleRef
.
For more information about creating Kubernetes RoleBinding
,
ClusterRoleBinding
, Role
, or ClusterRole
objects, see Using RBAC Authorization in the Kubernetes documentation.
If you want Amazon EKS to authorize the principalArn
(instead of, or
in addition to Kubernetes authorizing the principalArn
), you can
associate one or more access policies to the access entry using
associate_access_policy
. If you
associate any access policies, the principalARN
has all permissions
assigned in the associated access policies and all permissions in any
Kubernetes Role
or ClusterRole
objects that the group names are
bound to.
Metadata that assists with categorization and organization. Each tag consists of a key and an optional value. You define both. Tags don't propagate to any other cluster or Amazon Web Services resources.
A unique, case-sensitive identifier that you provide to ensure the idempotency of the request.
The username to authenticate to Kubernetes with. We recommend not specifying a username and letting Amazon EKS specify it for you. For more information about the value Amazon EKS specifies for you, or constraints before specifying your own username, see Creating access entries in the Amazon EKS User Guide.
The type of the new access entry. Valid values are Standard
,
FARGATE_LINUX
, EC2_LINUX
, and EC2_WINDOWS
.
If the principalArn
is for an IAM role that's used for self-managed
Amazon EC2 nodes, specify EC2_LINUX
or EC2_WINDOWS
. Amazon EKS
grants the necessary permissions to the node for you. If the
principalArn
is for any other purpose, specify STANDARD
. If you
don't specify a value, Amazon EKS sets the value to STANDARD
. It's
unnecessary to create access entries for IAM roles used with Fargate
profiles or managed Amazon EC2 nodes, because Amazon EKS creates entries
in the aws-auth
ConfigMap
for the roles. You can't change this value
once you've created the access entry.
If you set the value to EC2_LINUX
or EC2_WINDOWS
, you can't specify
values for kubernetesGroups
, or associate an AccessPolicy
to the
access entry.