Domino advanced credential propagation for AWS with EKS Pod Identity

In a previous article, we saw how the IAM role for Service Accounts (IRSA) can be utilized within Domino workloads (Apps, Jobs, and Workspaces) for assuming IAM roles. There are situations where IRSA can be operationally challenging to use. AWS provides another mechanism to assume IAM roles within Kubernetes workloads known as EKS Pod Identity to address these challenges. However, this approach has its own tradeoffs.

In this article we will explore what these operational challenges are and how EKS Pod Identity can be used within Domino workloads. We’ll look at specific situations where this approach is more suitable than the IRSA approach — and describe new challenges users will face when using this approach.

EKS Pod Identity vs. IRSA

In most cases, EKS administrators or Domino administrators, do not own the roles and policies defined in the AWS Identity and Access Management (IAM). When using IRSA, a Domino workload can assume any AWS role assigned to it. However, the IAM owner has to update the trust policy of the IAM role to explicitly point to the OIDC provider associated with the EKS cluster. This OIDC provider is unique for each EKS cluster. This has been considered to be one of the major operational challenges of IRSA when Domino upgrades are done using the Blue-Green upgrade mechanism. After each upgrade the trust policies for all roles assumed by kubernetes service account associated with a IAM role need to be updated with the new EKS cluster’s OIDC provider endpoint. 

If your EKS team owned these IAM roles and the associated trust policies, updating them is trivial. But if your EKS team does not own them and these roles are used outside of the EKS clusters, this presents a significant operational challenge. It can also be argued that, delegating the mapping of Kubernetes Service Accounts to IAM role via a separate IAM team is a good security practice. That’s because a separate team can impose additional safeguards when assigning roles to Kubernetes workloads. EKS Pod Identities are introduced by AWS to address this operational challenge.

Note: This document will provide you with detailed guidance. Please speak with your Domino Professional Services contact for additional information, assistance, and implementation support.

• New EKS Cluster for each Domino version
  Domino recommends using EKS Pod Identity when your policy is to deploy new Domino versions on new EKS clusters and your EKS administrators do not own the definitions of the IAM role being assumed by Domino workloads. In a Blue/Green scenario when you start the Green EKS cluster and install Domino on it, you will need to modify the trust relationship of each IAM role assumed by the Domino Workload to include the OIDC provider of the Green Domino. After the Blue EKS cluster is retired, you will need to remove the references to the OIDC provider of the Blue EKS cluster. This imposes an operational burden on the IAM Team. Furthermore, in most cases your internal policies won't permit you to make these changes without proper approvals in place adding more pressures on the operational process.
• Service Accounts Mapping to a single IAM role
  Domino Service Accounts exist, so a Domino admin can create these for executing jobs in production. The number of users in Domino is usually a stable number or changes less often. However, new jobs are created frequently. It is common for a job to be executed by a Domino Service Account. It is also good practice to limit a Service Account to only a small set of jobs. This allows fine grained access control granularity for the job owner (Domino Service Account). Having to frequently update an AWS roles trust policy to allow a service account to assume a role is operationally challenging unless the EKS admin owns the IAM role which the service account needs to assume. This situation also demonstrates that IRSA vs. EKS Pod Identities are not mutually exclusive choices. We can support both, IRSA for users (enabling them to switch roles inside a workload) and EKS Pod Identity for service accounts because service accounts usually need to assume a single role for the task they are responsible for.
• You plan to use Domino Credentials Propagation, but would like to use Domino Service Accounts to run jobs via automation processes
  While credential propagation works with a Domino user, a Domino Service Account cannot utilize Domino Credential’s Propagation feature. The reason being the Domino feature is tied to SAML integration with AWS IAM and Domino Service Accounts do not authenticate via SAML.
  
  A service account typically would be mapped to a single IAM role for the specific purpose of performing a task. One-to-one mapping for a service account to an IAM role makes operational sense. If you wish to run the same Domino Job but use different AWS IAM roles, it would make sense to create two separate service accounts in Domino and map these separate IAM roles to each of these service accounts respectively.