JetBrains CodeCanvas 2024.1 Help

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

  1. Create a ServiceAccount in the Kubernetes cluster where your dev environments are running.

  2. Create a role with the necessary permissions to access the external service:

  3. Bind the role to the ServiceAccount.

  4. On the sidebar, choose Administration, then Cloud Policy.

  5. 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.

  6. Click Save.

  7. Go to the Computing Platform page, open the platform where dev environments run (the same platform you specified in the policy), and click Edit.

  8. 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.

  9. 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.

  10. 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.

    Template Cloud policy
Last modified: 17 May 2024