Documentation Index
Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
Use this file to discover all available pages before exploring further.
Overview
Support Access Management gives you visibility and control over CoreWeave employee access to your environment. All access is:
- Request-based: CoreWeave employees must submit a Teleport access request before accessing any resource.
- Customer-approved: Access is only granted after a member of your organization with the
Access Request Approver role approves the request.
- Time-bound: Approved access expires automatically after 8 hours.
- Auditable: All sessions and the actions taken within them are logged.
Included systems
CoreWeave employees may request access to different systems within a CKS environment. The following table describes the specific systems and their typical methods of access:
| System | Typical method of access |
|---|
| CoreWeave Kubernetes Service (CKS) | kubectl CLI |
| Physical servers underlying a CKS cluster | SSH |
Access to CKS clusters
When CoreWeave requests access to your CKS cluster, the request specifies the level of access needed. When you review the request, you see the requested role and can deny the request if the permissions are inappropriate. The roles that CoreWeave employees may request are as follows:
| ClusterRole | Permissions |
|---|
teleport-cluster-viewers | Read-only access to most resources, but no access to Secret resources |
teleport-cluster-super-admins | Full access to all Kubernetes resources |
Access to physical servers
In some situations, CoreWeave employees may need to access your physical servers through SSH. This enables CoreWeave to run low-level networking diagnostics, troubleshoot issues with Kubelets, and more. CoreWeave typically requests login as the acc user, which has sudo access.
Managing access requests
Receiving access request notifications
When a CoreWeave employee requests access to a system within your CKS environment, you receive a notification. This notification includes a link to the Cloud Console, where you can review the details of the request. These details include the resources and permissions that the CoreWeave employee is requesting access to, and the reason for the request.
By default, CoreWeave delivers notifications to a designated, shared Slack channel. Additional notification channels, such as email, can be configured on request. If you enable Support Access Management, CoreWeave requires that you monitor your notification channel at all times to review and approve access requests promptly.
If you use the default shared Slack channel for notifications, any member of your organization in that channel can see request notifications. However, regardless of notification channel, only members of your organization with the Access Request Approver role can review the request details in the Console UI.
Users with the Access Request Approver role within your organization can approve or deny all access requests to resources in your CKS environment.
New access requests appear in the Pending state in the Cloud Console:
Approving requests
After reviewing an access request, you can approve it in the Console to grant CoreWeave access to your environment. Approved requests display the date and time of approval and identify the person in your organization who approved them:
By default, approved access requests remain valid for 8 hours, after which the CoreWeave employee’s access is revoked and the session terminated.
Denying requests
After reviewing an access request, you can deny it. Denied requests display the date and time of denial and identify the person in your organization who denied them:
When a request is denied, CoreWeave does not receive access to your environment until a subsequent request is submitted and approved.
Expired requests
After receiving an access request, you have 2 hours to either approve or deny it. Requests that do not receive a response within 2 hours automatically expire and do not grant CoreWeave any access to your environment. If this occurs, CoreWeave informs you that the requested resource will not be accessed, and may send a new request or attempt to troubleshoot without access to the system.
Any time between CoreWeave delivering the notification that access has been requested and you approving the request does not count as downtime against CoreWeave SLAs.If any component involved in the access request and approval flow experiences downtime, and immediate access to your cluster or physical server is required, CoreWeave requests written approval through Slack or email.
Logs and forwarding
CoreWeave can provide three types of logs related to support access activity:
| Teleport audit logs | Kubernetes audit logs | Teleport session logs |
|---|
| Contents | Every access request, approval, and denial | User, resource, and authorization details of all Kubernetes API interactions | Commands executed during approved access periods |
| Delivery | Forwarded in real time through CoreWeave Telemetry Relay | Available in CoreWeave Grafana; forwarded in real time through Telemetry Relay | Provided on request with a 24-hour turnaround |
CoreWeave makes no commitment to retain Teleport audit logs or Kubernetes audit logs for the purpose of providing them to you at a later date.
Teleport audit logs
Teleport audit logs contain every access request, approval, and denial related to the in-scope resources. CoreWeave can forward Teleport audit logs automatically through CoreWeave Telemetry Relay. CoreWeave labels these audit logs to distinguish them from Kubernetes logs.
After forwarding, audit log management is under your full control. Because CoreWeave may not be able to resend previously forwarded logs, follow best practices for log retention within your organization.
Kubernetes audit logs
Kubernetes audit logs contain user actions, resource changes, authentication details, and metadata associated with all CKS cluster API interactions. CoreWeave Grafana includes a Kubernetes audit log dashboard to view and query these logs in a tabular format. CoreWeave can also forward Kubernetes audit logs automatically through Telemetry Relay.
Teleport session logs
Teleport session logs contain detailed records of the commands executed by the CoreWeave employee during their approved period of access.
CoreWeave can provide session logs on request, with a turnaround time of 24 hours. CoreWeave verifies that any requests for session logs were initiated or approved by a user with the Access Request Approver role before providing the logs.
Session logs remain available for forwarding for a period of 12 months after the start of the session.
System architecture
CoreWeave employees can only access Teleport through the secure corporate access network, using a CoreWeave-monitored device such as a company-issued laptop. When Support Access Management is enabled, only users with the Access Request Approver role in your organization can approve Teleport requests. The following diagram details the system architecture for Support Access Management:
Getting started
To enable Support Access Management, contact Support.
After Support Access Management is enabled, CoreWeave recommends assigning the Access Request Approver role to multiple members of your organization across different time zones to ensure requests can be approved at any time. Access requests expire after 2 hours without a response.
To enable log forwarding for support access activity, configure Telemetry Relay.
