Manage Access Keys

To access Object Storage, users must authenticate their requests with Access Keys. This guide explains how to create and revoke Access Keys using the Object Storage API with either Cloud Console tokens or SAML assertions.

Create Key with a Cloud Console token

Create Access Keys

To manage Access Keys, you need an API Access Token with admin permissions.

The Object Storage API provides an endpoint to create permanent keys, or temporary Access Keys with a specified duration.

Permanent keys

Permanent keys do not expire and can be used indefinitely. To create a permanent access key, set durationSeconds to 0 in a JSON object. The value of 0 in the example data.json indicates that the key does not expire.

data.json

{
  "durationSeconds": 0
}

Then, submit the request to the /access-key endpoint with the JSON object in the body. Replace {API_ACCESS_TOKEN} with your API access token.

Example request

$
curl -X POST https://api.coreweave.com/v1/cwobject/access-key \
       -H "Content-Type: application/json" \
       -H "Authorization: Bearer {API_ACCESS_TOKEN}" \
       -d @data.json

A successful response returns the key with the expiry field set to 1970-01-01T00:00:00Z, which indicates that the key does not expire.

Response status code 200

{
    "accessKeyID": "CWABCDEFGHIJKLMN",
    "expiry": "1970-01-01T00:00:00Z",
    "principalName": "coreweave/[email protected]",
    "secretKey": "cwo1234567890abcdefghijklmnopqrstuvwxyz1234"
}

Temporary Access Keys

Create temporary Access Keys by setting durationSeconds to the desired duration in seconds. Temporary keys expire after the specified duration, which can be of any length.

To begin, create a JSON object that defines durationSeconds. The example below creates a key with a 300 second (5 minute) duration.

data.json

{
  "durationSeconds": 300
}

Submit the request to the /access-key endpoint with the JSON object in the body. Replace {API_ACCESS_TOKEN} with your API access token.

Example request

$
curl -X POST https://api.coreweave.com/v1/cwobject/access-key \
       -H "Content-Type: application/json" \
       -H "Authorization: Bearer {API_ACCESS_TOKEN}" \
       -d @data.json

A successful response returns the key. The expiry field is set to the time the key expires.

Response status code 200

{
    "accessKeyID": "CWABCDEFGHIJKLMN",
    "expiry": "2024-01-01T09:15:01Z",
    "principalName": "coreweave/[email protected]",
    "secretKey": "cwo1234567890abcdefghijklmnopqrstuvwxyz1234"
}

Revoke Access Keys

The Object Storage API provides endpoints to revoke individual Access Keys, or all keys associated with a principal.

Revoke an individual access key

To revoke an access key, first create a JSON object that specifies the key ID, such as the example data.json.

data.json

{
  "accessKey": "CWABCDEFGHIJKLMN"
}

Then, submit the request to the /revoke-access-key/access-key endpoint with the JSON object in the body. Replace {API_ACCESS_TOKEN} with your API access token.

Example request

$
curl -X POST https://api.coreweave.com/v1/cwobject/revoke-access-key/access-key \
       -H "Content-Type: application/json" \
       -H "Authorization: Bearer {API_ACCESS_TOKEN}" \
       -d @data.json

A successful response returns an empty object and the key is revoked.

Response status code 200

{}

Revoke all Access Keys for a principal

To revoke all Access Keys for a principal, create a JSON object that specifies the principal name.

data.json

{
  "principalName": "coreweave/[email protected]"
}

Then, submit the request to the /revoke-access-key/principal endpoint with the JSON object in the body. Replace {API_ACCESS_TOKEN} with your API access token.

Example request

$
curl -X POST https://api.coreweave.com/v1/cwobject/revoke-access-key/principal \
       -H "Content-Type: application/json" \
       -H "Authorization: Bearer {API_ACCESS_TOKEN}" \
       -d @data.json

A successful response returns an empty object and all keys for the principal are revoked.

Response status code 200

{}

Create Key with a SAML assertion

When a user performs an HTTP POST request to the https://api.coreweave.com/v1/cwobject/temporary-credentials/saml endpoint. Within the request, the user provides:

• an optional duration,
• the IdP Identifier returned by the IdP registration, and
• a SAML assertion configured as desired.

Example request

{
    "orgID": <your organization ID>,
    "duration": <desired duration in seconds for the credentials to survive>,
    "samlResponse": <base64 encoded SAML XML payload>
}

CoreWeave then validates the SAML assertion, parsing the role and principal from the assertion. If validation is successful, CoreWeave returns an API key pair comprised of an Access Key and a Secret Key, which allow the user to authenticate to CoreWeave AI Object Storage.

If duration is set, the key pair is considered valid for as long as that duration. If the key pair expires, the steps above must be repeated to provision a new one.

Learn more

See How to: Create an API Access Token.

SAML assertion key values

In order to successfully authenticate any principal or subject and provide the necessary key pairs to use AI Object Storage, CoreWeave requires these specific attributes to be present inside any SAML assertion. Every SAML Role must have permissions granted via SAML assertion in order to perform any actions on AI Object Storage buckets.

Role

<Attribute Name="https://coreweave.com/SAML/Attributes/Role">
  <AttributeValue>role-name</AttributeValue>
</Attribute>

PrincipalName

<Attribute Name="https://coreweave.com/SAML/Attributes/PrincipalName">
  <AttributeValue>principal-name</AttributeValue>
</Attribute>

Attribute Name	Definition
https://coreweave.com/SAML/Attributes/Role	Denotes the role for the credential this call generates. If a request is made using these credentials, the role attached to them is validated using the bucket policy. Appears in audit logs as the role used to gain access.
https://coreweave.com/SAML/Attributes/PrincipalName	Denotes the principal that the credentials are for; that is, the actor making the requests. Can also be used in the bucket policy if desired. Appears in audit logs as the principal that gained access.

Each authenticated key pair is treated as an individual user for access, and can be used to provide granular modification of permissions. These permissions may grant read and/or write permissions, which include permissions for modifying the bucket policies on buckets they own or are allowed to access.

Access policies for CoreWeave AI Object Storage are evaluated at the organization level, allowing users to be assigned privileges in groups. Users assigned to a role will only gain the access privileges granted to that role's key pair.

Example SAML assertion

Click to expand: Example SAML assertion

Example SAML assertion

   <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://signin.aws.amazon.com/saml" InResponseTo="" IssueInstant="2024-08-19T21:56:05" Version="2.0">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">my-org.com</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"></samlp:StatusCode>
  </samlp:Status>
  <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" IssueInstant="2024-08-19T21:56:05" Version="2.0">

    <saml:Issuer>my-org.com</saml:Issuer>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">[email protected]</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
          <saml:SubjectConfirmationData InResponseTo="" NotOnOrAfter="2024-08-19T22:01:05" Recipient="https://signin.aws.amazon.com/saml"></saml:SubjectConfirmationData>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2024-09-18" NotOnOrAfter="2024-10-19T22:01:05">
      <saml:AudienceRestriction>
        <saml:Audience>https://signin.aws.amazon.com/saml</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2024-08-19T21:56:05" SessionIndex="sess_index-fj6-7d8e-4e63-a282-nfkejelca6778">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="https://aws.amazon.com/SAML/Attributes/RoleSessionName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue>[email protected]</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="https://aws.amazon.com/SAML/Attributes/SessionDuration" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue>900</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="https://aws.amazon.com/SAML/Attributes/Role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue>arn:aws:iam::366768993934:role/SSOViewOnly,arn:aws:iam::459684590682:saml-provider/my-provider_sso</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Example access policy

Here is an example of a basic access policy that, if submitted, would allow users to read and write to buckets, without allowing any added privileges.

Example: basic-policy.json

{
    "version": "v1alpha1",
    "name": "give-saml-access",
    "statements": [
        {
            "name": "object-reader-allow",
            "effect": "Allow",
            "actions": [
                "s3:Get*",
                "s3:List*"
            ],
            "resources": ["test-bucket/*"],
            "principals": ["role/<reader-role>"]
        },
        {
            "name": "object-reader-deny",
            "effect": "Deny",
            "actions": [
                "s3:GetBucketPolicy",
                "s3:ListAllMyBuckets",
                "s3:ListMultipartUploadParts",
                "s3:ListBucketMultipartUploads"
            ],
            "resources": ["test-bucket/*"],
            "principals": ["role/<reader-role>"]
        },
        {
            "name": "object-writer-allow",
            "effect": "Allow",
            "actions": ["s3:*"],
            "resources": ["test-bucket/*"],
            "principals": ["role/<writer-role>"]
        },
        {
            "name": "object-writer-deny",
            "effect": "Deny",
            "actions": ["s3:PutBucketPolicy"],
            "resources": ["test-bucket/*"],
            "principals": ["role/<writer-role>"]
        },
        {
            "name": "object-admin-access",
            "effect": "Allow",
            "actions": ["*"],
            "resources": ["*"],
            "principals": ["role/<admin-role>"]
        }
    ]
}

Important

CoreWeave does not provide role management for AI Object Storage access. Role management for CoreWeave AI Object Storage is the responsibility of the client. CoreWeave assumes that any access given to a role via a SAML assertion provided by an organization's IdP is valid.