Struct CreatePodIdentityAssociationInput 

#[non_exhaustive]
pub struct CreatePodIdentityAssociationInput {
    pub cluster_name: Option<String>,
    pub namespace: Option<String>,
    pub service_account: Option<String>,
    pub role_arn: Option<String>,
    pub client_request_token: Option<String>,
    pub tags: Option<HashMap<String, String>>,
    pub disable_session_tags: Option<bool>,
    pub target_role_arn: Option<String>,
}

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

cluster_name: Option<String>

The name of the cluster to create the EKS Pod Identity association in.

namespace: Option<String>

The name of the Kubernetes namespace inside the cluster to create the EKS Pod Identity association in. The service account and the Pods that use the service account must be in this namespace.

service_account: Option<String>

The name of the Kubernetes service account inside the cluster to associate the IAM credentials with.

role_arn: Option<String>

The Amazon Resource Name (ARN) of the IAM role to associate with the service account. The EKS Pod Identity agent manages credentials to assume this role for applications in the containers in the Pods that use this service account.

client_request_token: Option<String>

A unique, case-sensitive identifier that you provide to ensure the idempotency of the request.

tags: Option<HashMap<String, String>>

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.

The following basic restrictions apply to tags:

• Maximum number of tags per resource – 50

• For each resource, each tag key must be unique, and each tag key can have only one value.

• Maximum key length – 128 Unicode characters in UTF-8

• Maximum value length – 256 Unicode characters in UTF-8

• If your tagging schema is used across multiple services and resources, remember that other services may have restrictions on allowed characters. Generally allowed characters are: letters, numbers, and spaces representable in UTF-8, and the following characters: + - = . _ : / @.

• Tag keys and values are case-sensitive.

• Do not use aws:, AWS:, or any upper or lowercase combination of such as a prefix for either keys or values as it is reserved for Amazon Web Services use. You cannot edit or delete tag keys or values with this prefix. Tags with this prefix do not count against your tags per resource limit.

disable_session_tags: Option<bool>

Disable the automatic sessions tags that are appended by EKS Pod Identity.

EKS Pod Identity adds a pre-defined set of session tags when it assumes the role. You can use these tags to author a single role that can work across resources by allowing access to Amazon Web Services resources based on matching tags. By default, EKS Pod Identity attaches six tags, including tags for cluster name, namespace, and service account name. For the list of tags added by EKS Pod Identity, see List of session tags added by EKS Pod Identity in the Amazon EKS User Guide.

Amazon Web Services compresses inline session policies, managed policy ARNs, and session tags into a packed binary format that has a separate limit. If you receive a PackedPolicyTooLarge error indicating the packed binary format has exceeded the size limit, you can attempt to reduce the size by disabling the session tags added by EKS Pod Identity.

target_role_arn: Option<String>

The Amazon Resource Name (ARN) of the target IAM role to associate with the service account. This role is assumed by using the EKS Pod Identity association role, then the credentials for this role are injected into the Pod.

When you run applications on Amazon EKS, your application might need to access Amazon Web Services resources from a different role that exists in the same or different Amazon Web Services account. For example, your application running in “Account A” might need to access resources, such as Amazon S3 buckets in “Account B” or within “Account A” itself. You can create a association to access Amazon Web Services resources in “Account B” by creating two IAM roles: a role in “Account A” and a role in “Account B” (which can be the same or different account), each with the necessary trust and permission policies. After you provide these roles in the IAM role and Target IAM role fields, EKS will perform role chaining to ensure your application gets the required permissions. This means Role A will assume Role B, allowing your Pods to securely access resources like S3 buckets in the target account.

Implementations

impl CreatePodIdentityAssociationInput

pub fn cluster_name(&self) -> Option<&str>

The name of the cluster to create the EKS Pod Identity association in.

pub fn namespace(&self) -> Option<&str>

The name of the Kubernetes namespace inside the cluster to create the EKS Pod Identity association in. The service account and the Pods that use the service account must be in this namespace.

pub fn service_account(&self) -> Option<&str>

The name of the Kubernetes service account inside the cluster to associate the IAM credentials with.

pub fn role_arn(&self) -> Option<&str>

The Amazon Resource Name (ARN) of the IAM role to associate with the service account. The EKS Pod Identity agent manages credentials to assume this role for applications in the containers in the Pods that use this service account.

pub fn client_request_token(&self) -> Option<&str>

A unique, case-sensitive identifier that you provide to ensure the idempotency of the request.

pub fn tags(&self) -> Option<&HashMap<String, String>>

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.

The following basic restrictions apply to tags:

• Maximum number of tags per resource – 50

• For each resource, each tag key must be unique, and each tag key can have only one value.

• Maximum key length – 128 Unicode characters in UTF-8

• Maximum value length – 256 Unicode characters in UTF-8

• If your tagging schema is used across multiple services and resources, remember that other services may have restrictions on allowed characters. Generally allowed characters are: letters, numbers, and spaces representable in UTF-8, and the following characters: + - = . _ : / @.

• Tag keys and values are case-sensitive.

• Do not use aws:, AWS:, or any upper or lowercase combination of such as a prefix for either keys or values as it is reserved for Amazon Web Services use. You cannot edit or delete tag keys or values with this prefix. Tags with this prefix do not count against your tags per resource limit.

pub fn disable_session_tags(&self) -> Option<bool>

Disable the automatic sessions tags that are appended by EKS Pod Identity.

EKS Pod Identity adds a pre-defined set of session tags when it assumes the role. You can use these tags to author a single role that can work across resources by allowing access to Amazon Web Services resources based on matching tags. By default, EKS Pod Identity attaches six tags, including tags for cluster name, namespace, and service account name. For the list of tags added by EKS Pod Identity, see List of session tags added by EKS Pod Identity in the Amazon EKS User Guide.

Amazon Web Services compresses inline session policies, managed policy ARNs, and session tags into a packed binary format that has a separate limit. If you receive a PackedPolicyTooLarge error indicating the packed binary format has exceeded the size limit, you can attempt to reduce the size by disabling the session tags added by EKS Pod Identity.

pub fn target_role_arn(&self) -> Option<&str>

The Amazon Resource Name (ARN) of the target IAM role to associate with the service account. This role is assumed by using the EKS Pod Identity association role, then the credentials for this role are injected into the Pod.

When you run applications on Amazon EKS, your application might need to access Amazon Web Services resources from a different role that exists in the same or different Amazon Web Services account. For example, your application running in “Account A” might need to access resources, such as Amazon S3 buckets in “Account B” or within “Account A” itself. You can create a association to access Amazon Web Services resources in “Account B” by creating two IAM roles: a role in “Account A” and a role in “Account B” (which can be the same or different account), each with the necessary trust and permission policies. After you provide these roles in the IAM role and Target IAM role fields, EKS will perform role chaining to ensure your application gets the required permissions. This means Role A will assume Role B, allowing your Pods to securely access resources like S3 buckets in the target account.

impl CreatePodIdentityAssociationInput

pub fn builder() -> CreatePodIdentityAssociationInputBuilder

Creates a new builder-style object to manufacture CreatePodIdentityAssociationInput.

Trait Implementations

impl Clone for CreatePodIdentityAssociationInput

fn clone(&self) -> CreatePodIdentityAssociationInput

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for CreatePodIdentityAssociationInput

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl PartialEq for CreatePodIdentityAssociationInput

fn eq(&self, other: &CreatePodIdentityAssociationInput) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl StructuralPartialEq for CreatePodIdentityAssociationInput