Using Workload Identity Federation and SAML

Create Access Keys using Workload Identity Federation and SAML Assertions

Create Key with a SAML assertion and Workload Identity Federation

Keys created using SAML assertions and Workload Identity Federation are created by submitting an HTTP POST request to the https://api.coreweave.com/v1/cwobject/temporary-credentials/saml endpoint. Within the request, the user provides:

• a duration in seconds, with a maximum lifetime of 12 hours,
• the organization ID,
• the Workload Federation configuration ID generated on the Cloud Console, and
• a SAML assertion, configured as desired, typically generated by an IdP.

Example

{
  "durationSeconds": 300,
  "orgId": "<MY_ORG_ID>",
  "configId": "<WORKLOAD_FEDERATION_CONFIG_ID>",
  "samlResponse": "<BASE64_ENCODED_SAML_RESPONSE>"
}

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.

The key pair is considered valid for the length of the set duration. Once 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.