Workspace Examples

    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 value—409 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
        • If the matching Service or Route’s host is an absolute value, a conflict is reported—409 Conflict

    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 Kong creates at migration time—e.g., RBAC credentials, which are provisioned at migration time as a convenience

    It will also hold entities that are created without being explicitly assigned to a specific workspace.

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

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

    A more interesting example would be segmenting entities by teams; for the sake of example, let’s say they are teamA, teamB, and teamC.

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

    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. {
    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"

    With this, Teams A, B, and C will have the freedom to operate their guest consumer independently, choosing authentication plugins or doing any other operation that is allowed in the non-workspaced Kong world.