Access your infrastructure

In order to access infrastructure you must assume the role of an account that has rights in the cloud that houses the deployed application environment.

Collect information

From the Find environment info collect

  • Account Id

  • Role

Assume Role

You will need to assume the role each time you want to access the cluster.

aws sts assume-role \
--role-arn arn:aws:iam::<account_id>:role/<role> \
--role-session-name $USER

Note: on a unix-esque system, this will name the session after your logged-in user.

Update kube config

This step only needs to be done once. It creates an entry in your ~/.kube/config file.

aws eks \
--region <region> \
update-kubeconfig \
--name <cluster_name> \
--alias <something easy to type that is descriptive> \
--profile <cluster_name>

Optional: alias kubectl

It can become cumbersome to type kubectl a lot, a common trick is to alias it to k, add the following line in ~/.profile (create the file if it doesn't already exist)

alias k=kubectl

You can run source ~/.profile to have the changes take effect in the current shell

NOTE: in the discussion that follows "alias" refers to the cluster alias set in the previous step, and not the unix command "alias" shown above.

Optional: set the default namespace

Adding a default namespace for the cluster makes life a bit easier, as you don't need to include it every time you call kubectl.

The environment type can be found on the tile for the environment you are configuring:

k config set-context --cluster='<alias>' --namespace='<environment type>'

NOTE: setting the kubectl context is not the same as selecting it.

Select the kubectl context

Kubectl works with one cluster at a time, the selected cluster is called the context and that is the cluster kubectl commands will execute against.

You can view the list of contexts with k config get-contexts the starred context is the current one.

You can also view the current context with k config current-context.

To use the context, run k config use-context <alias>.

FWIW - we find the set-context vs. use-context a little confusing, but setting the context refers to updating kubectl's internal configuration, e.g. setting information about the particular context. Since no one asked, we'd prefer update-context and select-context.


To ensure everything is configured run k get pods to see a list of containers running in your environment.

NOTE: there is an additional "jump-pod" that can be used for console access into your cluster that can be used to access managed services that were provisioned for this environment.

Last updated