Workspace Examples

    Workspaces provide a way to segment Kong entities—entities in a workspace are isolated from those in other workspaces. That said, entities such as Services and Routes have “routing rules”, which are pieces of info attached to Services or Routes—such as HTTP method, URI, or host—that allow a given proxy-side request to be routed to its corresponding upstream service.

    Admins configuring Services (or Routes) in their workspaces do not want traffic directed to their Services or Routes to be swallowed by Services or Routes in other workspaces; Kong allows them to prevent such undesired behavior—as long as certain measures are taken. Below we outline the conflict detection algorithm used by Kong to determine if a conflict occurs.

    • At Service or Route creation or modification time, Kong runs its internal router:
      • If no Services or Routes are found with matching routing rules, the creation or modification proceeds
      • If Services or Routes with matching routing rules are found within the same workspace, proceed
      • If Services or Routes are found in a different workspace:
        • If the matching Service or Route does not have an associated value409 Conflict
        • If the matching Service or Route’s host is a wildcard
          • If they are the same, a conflict is reported—409 Conflict
          • If they are not equal, proceed

    Kong creates a default workspace—unsurprisingly named default—whose goal is to group all existing entities in Kong, where “existing entities” refers to:

    • Entities that were created in operation in previous versions & in case one is migrating from an older Kong version;
    • Entities that Kong creates at migration time—e.g., RBAC credentials, which are provisioned at migration time as a convenience

    That said, it’s worth noting that the default workspace is a workspace as any other, the only difference being that it’s created by Kong, at migration time.

    (Examples will be shown using the httpie HTTP command line client.)

    In a fresh Kong Gateway install, submit the following request:

    Each of these teams has its own set of entities—say, upstream services and routes—and want to segregate their configurations and traffic; they can achieve that with workspaces.

    1. http POST :8001/workspaces name=teamA
    2. {
    3. "created_at": 1528843468000,
    4. "id": "735af96e-206f-43f7-88f0-b930d5fd4b7e",
    5. }
    1. http POST :8001/workspaces name=teamC
    2. {
    3. "name": "teamC",
    4. "created_at": 1529628622000,
    5. "id": "34b28f10-e1ec-4dad-9ac0-74780baee182"

    At this point, if we list workspaces, we will get a total of 4—remember, Kong provisions a “default” workspace and, on top of that, we created other 3.

    Different teams—belonging to different workspaces—are allowed to give any name to their entities. To provide an example of that, let’s say that Teams A, B, and C want a particular consumer named guest—a different consumer for each team, sharing the same username.

    1. http :8001/teamA/consumers username=guest
    2. {
    3. "id": "2e230275-2a4a-41fd-b06b-bae37008aed2",
    4. "type": 0,
    5. "username": "guest"
    6. }
    1. http :8001/teamC/consumers username=guest
    2. {
    3. "created_at": 1529703393000,
    4. "id": "5fb180b0-0cd0-42e1-8d75-ce42a54b2909",
    5. "type": 0,
    6. "username": "guest"