Access to Cloud Resources

Suppose your company has resources hosted in the cloud, for example, a database in Amazon RDS, an object storage in Amazon S3, an API server in Google Cloud, etc. These resources are required for development and testing purposes and should be accessible from user dev environments. Normally, users have to configure access to these resources manually by providing credentials or tokens to their dev environments. This is not only inconvenient but also insecure.

This is where CodeCanvas cloud policies come into play. To provide access to cloud resources from dev environments, cloud policies use Kubernetes service accounts – non-user accounts providing identity in a Kubernetes cluster. A cloud policy assigns a specific ServiceAccount to a dev environment instance type. As a result, dev environment pods of this type can use the ServiceAccount to authenticate outside the cluster, e.g., to access cloud resources, API servers, and so on.

The benefits:

Simplifying the developer experience – Cloud policies eliminate the need for individual developers to manage keys or tokens.
Enforcing least privilege – You can grant only the minimum necessary permissions to a specific ServiceAccount, i.e., to a dev environment. This reduces the risk of unauthorized access to sensitive resources.
Additional security layer – Cloud policies provide an additional layer of security as you manage access to cloud resources on the dev environment template level.

Supported cloud providers

Currently, cloud policies are supported for the following cloud providers:

The Kubernetes cluster with dev environments runs in:

AWS EKS (Amazon Elastic Kubernetes Service)
Google GKE (Google Kubernetes Engine)
Azure AKS (Microsoft Azure Kubernetes Service)

Resources run in:

AWS (Amazon Web Services)
GCP (Google Cloud Platform)
Azure (Microsoft Azure)

Set up authentication of dev environments in cloud services

Create a ServiceAccount in the Kubernetes cluster where your dev environments are running.
Create a role with the necessary permissions to access the external service:
- AWS EKS – IAM role
- Google GKE – Google service account
- Azure AKS – Managed identity
Bind the role to the ServiceAccount.
On the sidebar, choose Administration, then Cloud Policy.
Click New policy and specify the policy Name and other settings:
- Computing platform – the platform (e.g., a Kubernetes cluster) where dev environments run. Learn more
- Service Account – the ServiceAccount you created in step 1.
- Scope – the namespace scope for the policy (these are CodeCanvas namepspaces, not Kubernetes namespaces). It can be a specific namespace or all namespaces. A dev environment template must belong to one of the specified namespaces to be affected by the policy.
Click Save.
Go to the Computing Platform page, open the platform where dev environments run (the same platform you specified in the policy), and click Edit.
In Pod template YAML, add the following configuration depending on the platform:
spec: containers: - name: worker-main env: - name: WORKER_STEP_CONTAINER_PROPAGATION_ENV_VAR_KEYS value: "AWS_ROLE_ARN;AWS_WEB_IDENTITY_TOKEN_FILE;AWS_STS_REGIONAL_ENDPOINTS;AWS_DEFAULT_REGION;AWS_REGION" - name: WORKER_STEP_CONTAINER_PROPAGATION_PATHS value: "/var/run/secrets/eks.amazonaws.com"
spec: nodeSelector: iam.gke.io/gke-metadata-server-enabled: "true"
metadata: labels: azure.workload.identity/use: true spec: containers: - name: worker-main env: - name: WORKER_STEP_CONTAINER_PROPAGATION_ENV_VAR_KEYS value: "AZURE_AUTHORITY_HOST;AZURE_CLIENT_ID;AZURE_FEDERATED_TOKEN_FILE;AZURE_TENANT_ID" - name: WORKER_STEP_CONTAINER_PROPAGATION_PATHS value: "/var/run/secrets/azure"
Click Save.
Why do you need to add this configuration?
The configuration is required to propagate the necessary environment variables and files to the dev environment containers. The variables and files are used by the tools (e.g., the AWS CLI, Google Cloud SDK, Azure CLI) to authenticate and access the external services.
In CodeCanvas, a Kubernetes pod runs a worker container that, in turn, runs a dev environment container. This means that automatic authentication via service accounts is available to the worker container but not to the dev environment container. The YAML configuration ensures that the necessary environment variables and files are propagated to the dev environment container.
Ensure you have a dev environment instance type that uses the specified computing platform. You might want to limit the instance type's namespace scope to the same namespaces as the policy.
To apply the policy to dev environments, the namespace administrator must select the policy in the dev environment template settings. After that, the policy will be applied to new dev environments created from the template (existing dev environments won't be affected). All the required credentials or tokens will be automatically injected into the environments – the corresponding tools (e.g., the AWS CLI, Google Cloud SDK, Azure CLI) won't require authentication.

Last modified: 02 July 2024