Installing K10 on AWS

Prerequisites

Before installing K10 on Amazon EKS, it is important to determine the preferred authentication mechanism: either Long-term access keys or IAM Roles for service accounts. The choice of authentication mechanism will affect the necessary steps and prerequisites for the installation process.

AWS provides two types of authentication mechanisms for programmatic access:

• Long-term access keys

• IAM Roles for Service Accounts

If you opt for long-term access keys, you will need to provide the Access Key ID and Secret Access Key during the setup. In addition, you may optionally provide an additional IAM Role. The additional IAM Role allows for extra permissions to be granted to the identity authenticated with the long-term access key.

On the other hand, if you choose IAM Roles for service accounts, you would not need to provide the Access Key ID and Secret Access Key. Instead, you will need to ensure the presence of the required IAM role. Please consider the authentication mechanism that best suits your requirements and follow the appropriate steps and instructions provided to ensure a seamless authentication experience.

These mechanisms are designed to authenticate and authorize the programmatic interactions between scripts or command line interfaces and AWS services. Both authentication mechanisms provide secure programmatic access to AWS resources.

Let's dive into the details:

1. Long-term access keys: These keys are commonly used when authenticating programmatic access to AWS resources. When creating long-term access keys, you receive an Access key ID and a Secret Access Key. The Access Key ID serves as the identifier for the access key, and the Secret Access Key is a unique secret value used for authentication. During the Helm installation process, you are given the choice to assign a role. This role will be used during authentication when K10 initially authenticates using the provided Access Key ID and Secret Access Key, along with the additional assigned role.

   • During the Helm installation process, you can choose to configure long-term access secret keys and key IDs by providing the necessary key pairs: --set secrets.awsAccessKeyId and --set secrets.awsSecretAccessKey.

   • (Optional) In addition to the long-term access keys, you can choose to provide an additional IAM role. This additional role will be associated with the secrets.awsIamRole configuration parameter.

2. IAM Roles for Service Accounts: IAM roles are useful in scenarios where you want to provide access to AWS services without managing or exposing long-term access keys. To know more about it, refer to IAM Roles for Service Accounts.

AWS IAM roles grant access to AWS account resources to trusted entities. The following links contain information on how to create roles and other permission-related details:

• Using AWS IAM Roles with K10
  • Creating an IAM Policy
  • K10 installs with IAM Roles
    • Option I: Using IAM Role With a Kubernetes Service Account (EKS)
      • Enabling OIDC on your EKS Cluster
      • Creating an IAM Role for K10 Install
      • (Optional) Install K10 with an IAM role assumption
    • Option II: Using an IAM Role With an IAM User

Installing K10

To install on AWS, you need to define two environment variables that specify your access key id and secret access key. After doing so, just run the following command to install K10, the Kasten platform on either AWS EKS or any other Kubernetes distribution running on EC2.

$ helm install k10 kasten/k10 --namespace=kasten-io \
    --set secrets.awsAccessKeyId="${AWS_ACCESS_KEY_ID}" \
    --set secrets.awsSecretAccessKey="${AWS_SECRET_ACCESS_KEY}"

If you want K10 to assume an IAM Role in AWS infrastructure operations, refer to Using AWS IAM Roles with K10 on how to create and use the role.

For IAM Roles for Service Accounts, once the setup is completed, you will need to provide a token file to assign the role to the k10-k10 service account. With the assigned role, there is no need for Access Key and Secret Access Key. During the K10 installation, you can choose to manually configure the k10-k10 service account. For additional information, refer to Associate Service Account Role.

In some scenarios, it is advantageous to avoid pre-configuring a service account manually, and instead, leverage Helm's capabilities to streamline the process. By providing a role through the Helm package manager using the --set secrets.awsIamRole flag, the service account can be dynamically created.

AWS keys or IAM Roles need to have permissions that allow K10 to perform operations on EBS and, if needed, EFS and S3. The minimal set of permissions needed by K10 for integrating against different AWS services can be found here:

• Using K10 with AWS EBS
• Using K10 with AWS S3
• Using K10 with Amazon RDS
• Using K10 with AWS EFS
• Using K10 with AWS Secrets Manager
• Optional KMS Permissions

The above permissions can also be used in the context of IAM Policies and Roles. Refer to Using AWS IAM Roles with K10 for more information regarding IAM Policies and Roles.

EKS Authentication Setup

Finally, for end-to-end instructions on how to set up token-based authentication for AWS EKS clusters, please follow the documentation here.

Elastic File System Limitation

Currently, K10 supports backup and recovery of AWS Elastic File System (EFS) volumes. However, due to EFS limitations, cross-cluster EFS restores within the same region and across regions require manual intervention using the AWS CLI or AWS console using the below instructions.

• Using the K10 dashboard and AWS CLI for EFS Snapshot Migration
• Using the K10 dashboard and AWS Console for EFS Snapshot Migration

EKS IPv6 Clusters

To install K10 on an IPv6 cluster, run the following command:

$ helm install k10 kasten/k10 --namespace=kasten-io \
    --set secrets.awsAccessKeyId="${AWS_ACCESS_KEY_ID}" \
    --set secrets.awsSecretAccessKey="${AWS_SECRET_ACCESS_KEY}"
    --set general.network.enable_ipv6=true

This will enable IPv6 listeners for all required services. Same option can be used to enable IPv6 listeners for a dual-stack setup.

K10 was tested in IPv6-only setup only on AWS EKS platform. Although it is expected to work on other platforms as well.

Warning

Port-forwarding to K10 services may not work in IPv6-only setup with Dockershim CRI. Containerd CRI supports IPv6 port-forwarding since 1.5.2 release.

Validating the Install

To validate that K10 has been installed properly, the following command can be run in K10's namespace (the install default is kasten-io) to watch for the status of all K10 pods:

$ kubectl get pods --namespace kasten-io --watch

It may take a couple of minutes for all pods to come up but all pods should ultimately display the status of Running.

$ kubectl get pods --namespace kasten-io
NAMESPACE     NAME                                    READY   STATUS    RESTARTS   AGE
kasten-io     aggregatedapis-svc-b45d98bb5-w54pr      1/1     Running   0          1m26s
kasten-io     auth-svc-8549fc9c59-9c9fb               1/1     Running   0          1m26s
kasten-io     catalog-svc-f64666fdf-5t5tv             2/2     Running   0          1m26s
...

In the unlikely scenario that pods that are stuck in any other state, please follow the support documentation to debug further.

Validate Dashboard Access

By default, the K10 dashboard will not be exposed externally. To establish a connection to it, use the following kubectl command to forward a local port to the K10 ingress port:

$ kubectl --namespace kasten-io port-forward service/gateway 8080:8000

The K10 dashboard will be available at http://127.0.0.1:8080/k10/#/.

For a complete list of options for accessing the Kasten K10 dashboard through a LoadBalancer, Ingress or OpenShift Route you can use the instructions here.