AWS re:Invent is a learning conference hosted by AWS for the global cloud-computing community.
December 2nd, 2024 - December 6th, 2024
Las Vegas, Nevada
320
Read More
Enterprise security and governance for software development environments: A Coder guide
Mark Milligan
on March 7th, 2022
Updated on March 15th, 2022
Well-defined and executed security and governance processes are essential for any modern enterprise. However, processes designed for the enterprise as a whole are often overly burdensome for software developers. Required security software may limit engineers’ ability to install tools and libraries needed for their projects or hinder productivity by slowing their workstations to a crawl. Engineers required to use VDI solutions for their development environments often complain about unacceptable keyboard lag. Some organizations simply make exceptions for their engineers, which compromises security for the entire organization.
Coder's software development platform provides a solution, enabling the application of strict security processes without negatively impacting developer productivity.
In this post, we will explore Coder's security-related features and benefits that have made it a popular solution for enterprises in some of the most highly regulated industries in the world.
What Coder does
Coder is a self-hosted developer workspace platform that moves dev environments off of local machines or other solutions and into the enterprise’s on-premises or public cloud Kubernetes infrastructure.
Coder’s developer workspaces are Linux containers inside a dedicated Kubernetes pod where their IDEs, languages, frameworks, and dependencies reside. Each pod also has a dedicated Persistent Volume Claim (PVC), a virtual equivalent of the developer’s laptop hard drive, where the developer clones code repositories. As their name says, PVCs are persistent, so even if a pod and container shut down due to inactivity or an administrative rebuild, the checked-out source code and sensitive data safely remain in the PVC. When the workspace is rebuilt, the PVC will re-mount to the pod.
Moving Source code and data to your cloud infrastructure
The traditional model of software development where engineers write and test code on their personal workstations creates substantial risk for enterprise security and governance. In this model, when onboarding to a new project, the developer clones the project’s code repository from the company’s Git provider. A complete copy of the enterprise’s intellectual property in the form of source code now resides on the developer’s local computer, typically a laptop, and the developer begins modifying the code as necessary.
Once the code is on a developer’s laptop, however, there are multiple ways for it to be exfiltrated beyond the organization’s control including automated backups to a public cloud provider, being copied to a thumb drive, or the laptop could be stolen or even accidentally left in a rideshare. Whatever the threat vector, there is a potential monetary, brand, and competitive risk of the enterprise’s intellectual property ending up in the wrong hands.
With Coder, however, because the developer workspaces reside within the enterprise’s on-premises or public cloud Kubernetes infrastructure the cloned code repositories never reside on a developer’s laptop. The source code lifecycle remains the same as if the developer were using a local version and a laptop—they add, commit, and push their repository changes to the same enterprise’s Git provider, e.g., GitHub, GitLab, Bitbucket, or Azure DevOps, but the source code never leaves the enterprise’s control. Whether an employee or a contractor, when a developer leaves an enterprise, their authentication access is revoked to Coder, eliminating any risk of intellectual property theft.
Development environment insolation
Coder also protects against inappropriate access from within the organization by ensuring each workspace is isolated.
Coder leverages a built-in design in Kubernetes called a pod to encapsulate a developer’s workspace as a Linux container. A developer can have one-to-many workspaces in Coder and each workspace consists of a separate pod, inner container, and PVC. Only the developer who creates the workspace can physically access it and its PVC with an IDE.
Enterprises with pair programming requirements can leverage IDE vendor solutions like JetBrains’ Code with Me, VS Code’s LiveShare or collaboration tools like Zoom, Microsoft Teams, WebEx, and Google Meet for pair programming.
Vulnerability prevention with centralized image management
Coder workspaces are built from Docker images containing the IDEs, programming languages, frameworks, and related dependencies required for a developer to work on a project. An organization controls who is authorized to create these images and publish them to the enterprise’s container registry e.g., jFrog Artifactory, AWS ECR, Azure ACR, GCP Container Registry, Red Hat Quay, or Docker Hub.
By centralizing image management, an enterprise ensures consistency across all developer workspaces and effectively prevents developers from using older versions of dependencies with known vulnerabilities that can be exploited.
For example, in the recent Log4j vulnerability that impacted many Java applications, several customers reported using Coder to quickly and easily update the centralized developer images that contained IDEs that addressed the vulnerability. They were then able to automate rebuilds of developers’ workspaces, ensuring that no one was using a vulnerable environment.
Workspace definition governance (Workspaces as code)
While development environment workspaces are based on centrally defined and managed Docker images, there are additional controls and configurations that an enterprise would like to control, such as default CPU, GPU, memory, and storage.
Using either the image-level definitions or source-controlled Coder templates, administrators and organization managers can configure additional developer capabilities such as installing VS Code extensions, automatically cloning source code repositories and datasets, building the project including downloading dependencies, defining sharable dev URLs for developers and teammates to review a project’s running applications, and auto-starting applications as daemons.
Centralizing these configurations drives consistency but also increases developer productivity since when a workspace is built, a developer can begin to code and instantly add value.
Segmenting users with organizations
Coder administrators organize developers into groups called organizations that restrict which images their members may use to build workspaces. In addition to simplifying image management, this also helps prevent individual developers from gaining access to tools and resources to which they should not have access.
Learn more about organizations in Coder
Segmenting users with workspace providers
A key concept of Kubernetes management is namespaces, which partition a single Kubernetes cluster into multiple virtual clusters and prevent namespaced applications and pods from communicating across namespaces.
For small teams of developers, a single namespace in a Kubernetes cluster can house both the developer workspace pods and the Coder control plane—the central authority that provides authentication and supports the Coder dashboard and API.
However, Coder can also use namespaces to create groups of workspaces that are isolated from each other. Coder calls this additional layer of isolation a workspace provider. A workspace provider can even reside on a completely separate Kubernetes cluster than the Coder control plane. These workspace providers can be located in different availability zones or data centers.
Some customers use workspace providers to provide an additional layer of security above and beyond Coder organizations. These customers place developers working on particularly sensitive projects into a workspace provider running on a separate cluster than their less sensitive projects.
Other customers use workspace providers to assist with compliance with GDPR laws that regulate the storage of personal data.
Learn more about workspace providers.
Audit logging
Key to any enterprise’s security and governance is knowing who is doing what with their resources. Coder stores metadata on the logical objects of Coder (e.g. images, organizations, users, workspaces) in a relational database (PostgreSQL) and generates an audit log of how users interact with these objects.
The audit logs are accessible in the browser-based dashboard, exportable as a CSV file, and are automatically included in the underlying Kubernetes logs for review by an enterprise’s external tools like a SIEM.
When combined with a Git repository’s commit history, Coder’s audit logs provide a full record of activities involving the organization's source code and development environments.
Learn more about audit logging in Coder.
Workspace process logging
One of Coder’s high-value and unique features is an administratively-managed setting to log processes started by developers inside a workspace. The workspace process logging feature allows an organization to log all system-level processes executing in the workspace. It attaches a sidecar to the workspace that will log all processes users start in the workspace (e.g., commands executed in the terminal or system processes created by background services in CVM workspaces).
Tech risk and information security teams can review these logs for usage patterns and behavior either by viewing the output from the sidecar or sending it to a monitoring stack, such as CloudWatch, for further analysis. This capability is tamper-proof by a developer and centrally controlled.
Learn more about workspace process logging
User management and SSO
Although Coder comes with a built-in authentication system that is good for evaluations and small deployments, Coder leverages an open standard called OpenID Connect (OIDC) to integrate Coder with an enterprise’s Single Sign-On (SSO) system. Administrators can define whitelists within their SSO to prevent any user in an enterprise’s SSO system from automatically logging into Coder and consuming compute resources.
Authentication session tokens
When a user authenticates to a Coder deployment with their built-in or SSO password, Coder creates an authentication session token used by all future API calls for interacting with the browser-based dashboard, API, and Command Line Interface (CLI).
An authentication session token is required the first time a developer or administrator uses the CLI, and the session token is generated by redirecting the user to the browser-based dashboard to copy and paste the session token to proceed with using the CLI. The CLI also provides commands to create, list, regenerate and remove session tokens assigned to the user.
When using the Coder published API, such as for automating the creation of users and workspaces, users pass a valid session token as a cookie in the header section of a curl command.
Role-based Access Controls
Coder maintains Role-based Access Controls (RBAC) at the site-wide user level and the organization level.
At the site level, Coder provides four roles: * Site admin — grants full access to the system. There can only be one site admin per Coder installation. * Site manager — allows access to all administrative functionality in addition to basic usage rights. * Auditor — offers auditing functionality * Members — allows basic usage of Coder like creating workspaces and using IDEs, typically assigned to developers and data scientists.
At the organization level, there are two roles available: * Organization Manager — grants full administrative access to the organization and the ability to manage its images and members. Can view, modify, and delete workspaces belonging to members of the organization. * Organization member — grants basic organization access. Can use and view images belonging to the organization. Can create new images assigned to the organization. Can only access workspaces within their organization.
Securely sharing developer work in progress
When developers code on laptops, they often test their application on localhost. However, sharing an application running on localhost with a colleague for testing or feedback can be cumbersome, and is sometimes forbidden by an organization's security policies.
Because Coder is remotely installed and managed, developers can create a dev URL, a unique URL that uses Coder’s session token authentication to securely share a running application with colleagues.
Dev URLs leverage the existing authentication session token and TLS of the Coder deployment and dev URLs are stored securely in the PostgreSQL database along with other Coder deployment metadata.
A common use case for dev URLs is adding the link to a pull request, thereby allowing colleagues to review and test the feature change without having to manually create a development environment and run the application.
Learn more about dev URLs in Coder.
Secure Shell (SSH)
The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. SSH is often used as a secure method of cloning, pushing, and pulling code repositories.
Each Coder user is generated with an SSH public and private key. Developers can manually add their public SSH key to the enterprise’s Git provider to permit access. Alternatively, an administrator can create an OAuth application in the Git provider and add its credentials to a Coder deployment. Developers then link their Git provider to their Coder deployment with a one-time click of a button, eliminating the need to manually copy the public SSH key to the Git provider. Developers can then open a web terminal or use an integrated terminal in their favorite IDE and perform secure Git operations.
Another powerful use of SSH in Coder is running a terminal or IDE on your local computer or laptop and then securely connecting to a Coder workspace. Using the Coder CLI, a developer would run a config-ssh command that copies her private SSH key and the workspace hostnames into her local .ssh folder.
The developer can then run an ssh command to connect to a Coder workspace, or alternatively use a local VS Code or JetBrains IDE to connect, and begin coding with all the benefits of a local IDE experience and a secure session.
It is important to note that while using this method all of the source code remains contained within the Coder workspace and is never cloned to the developer’s laptop.
Many organizations do not allow opening port 22 due to security concerns, but the fucntionality just described does not require it. Coder actually tunnels SSH using the Coder CLI through HTTPS, and Coder leverages the authentication session token to prove the identity of the user. No exposure of port 22 is necessary.
Encryption in transit
Coder can be configured as part of the Kubernetes helm installation process to use TLS (Transport Security Layer) to encrypt all HTTP traffic between a local computer and a Coder deployment. Enterprises can configure their own Load Balancer and terminate TLS there, but Coder also uses WebRTC and UDP inside of HTTP which is encrypted by default. By using WebRTC, Coder provides end-to-end encryption from the browser and inside the Coder control and data planes.
Secret management
Coder leverages Kubernetes’ secret management to define, store, and retrieve secrets such as service account tokens and certificates that may be needed in a Coder deployment. Coder can also integrate with an enterprise’s secret system like HashiCorp’s Vault for other secrets such as mutual TLS with container registries.
Virtual Desktop Infrastructure enhancement
Many enterprises in regulated industries such as banking and public sector mandate that employees access corporate systems through a Virtual Desktop Infrastructure (VDI) platform like VMware, Citrix, Azure Virtual Desktop, or AWS WorkSpaces. In some cases, VDI may be implemented to support multi-factor authentication and prevent exfiltration via copy and paste. Some of Coder’s customers have developers access Coder from a browser they open within their VDI infrastructure. Because Coder is a browser-based platform from the ground up, the developer experience is fast and snappy within VDI.
In some cases, Coder may be used as an alternative to VDI for developers, meeting the security needs of the organization that drove its VDI adoption while providing developers with a better experience than VDI.
Key takeaways
Coder helps enterprises bring software ideas and projects to production more quickly. Coder also provides the first line of defense for enterprises to secure and protect their source code, sensitive data, and intellectual property from bad actor theft.
Enterprises that have long wanted to better govern and control software development now have a self-hosted platform that fits into their Kubernetes infrastructure to secure the developer experience while not impeding developer productivity.
To see how Coder can benefit your organization’s software production teams, sign up for a customized demostration or contact our sales team directly with your questions at [email protected].
Subscribe to our Newsletter
Want to stay up to date on all things Coder? Subscribe to our monthly newsletter and be the first to know when we release new things!