1. Workspaces enable traffic segmentation and allow teams of Admins to share the same Kong cluster but only interact with entities from their groups. Delegated Administration of the Gateway can be achieved by adding administrators to 'Teams', then assigning these Teams to 'workspaces’?
Yes, that is correct! Workspaces in Kong enable traffic segmentation and provide a way for different teams of administrators to share the same Kong cluster while interacting only with entities from their respective groups. This is achieved by adding administrators to teams and then assigning these teams to specific workspaces.
With workspaces, each team can have its own isolated environment to manage their services, routes, plugins, and other entities without interfering with other teams' workspaces. This helps to maintain the security, stability, and performance of the Kong cluster, while also streamlining the workflow of different teams.
In addition, workspaces also provide delegated administration capabilities, where the owner of a workspace can delegate certain privileges and permissions to other administrators in their team, without giving them full access to the entire Kong cluster. This allows for finer-grained access control and enhances the security of the Kong environment.
2. What is the default entity used for aggregating limits in the rate limiting advanced plugin?
The default entity used for aggregating limits in the rate limiting advanced plugin of Kong is the consumer.
By default, Kong applies rate limits based on the consumer entity, which represents the client making the request to the API. The consumer can be identified by a unique key such as an API key, an OAuth2 client ID, or a JWT token.
When a request is made to an API that has rate limiting enabled, Kong checks the current rate limit status of the consumer. If the consumer has exceeded their rate limit, Kong will return an HTTP 429 Too Many Requests response.
However, it is worth noting that the rate limiting advanced plugin in Kong provides a lot of flexibility and can be configured to use different entities for rate limiting, such as IP address, URL, or headers, depending on your specific use case. This can be achieved by configuring the plugin with the appropriate limit_by parameter.
3. What types of authorization does Kong provide?
Kong provides several types of authorization mechanisms that can be used to secure your APIs (Application Programming Interfaces). Some of the most used authorization plugins in Kong include:
Key Authentication: This plugin provides a simple authentication mechanism using a secret key that must be included in the request headers.
JWT Authentication: This plugin allows authentication using JSON Web Tokens (JWTs) that contain user information and are signed with a secret key.
OAuth2 Authentication: This plugin allows clients to authenticate and obtain access tokens using the OAuth2 protocol, which is widely used for delegated authorization.
ACL Authorization: This plugin allows you to define access control lists (ACLs) that determine which consumers can access specific APIs or routes.
RBAC Authorization: This plugin provides role-based access control (RBAC) capabilities, where different users or groups can be assigned specific roles that determine their access privileges to APIs or routes.
Mutual TLS Authentication: This plugin enables mutual authentication using Transport Layer Security (TLS) certificates, which helps to secure communication between clients and servers.
OpenID Connect: This plugin enables authentication using the OpenID Connect (OIDC) protocol, which is built on top of OAuth2 and provides additional identity verification features.
By using these authorization plugins, Kong provides a flexible and customizable way to secure your APIs and manage access control in a scalable and centralized manner.
4. You must specify a service for a plugin?
Yes, in Kong, you must specify a service for a plugin to associate the plugin with a specific service.
A plugin is a module that can be added to Kong to add functionality to the API Gateway. Plugins can be added to services, routes, or globally. When a plugin is added to a service or route, it only affects that specific service or route. When a plugin is added globally, it affects all services and routes.
When adding a plugin to a service or route, you need to specify the service or route ID to associate the plugin with the desired service or route. This can be done using the Kong Admin API, the Kong Dashboard, or by specifying the service or route ID in the configuration file for the plugin.
For example, if you want to add the rate-limiting plugin to a specific service in Kong, you will need to specify the service ID in the plugin configuration. Here is an example of how this can be done using the Kong Admin API.
5. Plugins can be applied globally or scoped to specific services or routes?
Yes, that is correct! In Kong, plugins can be applied globally or scoped to specific services or routes.
When a plugin is added globally, it is applied to all incoming requests that pass through the Kong API Gateway. This means the plugin will affect all services and routes configured in Kong. Global plugins are typically used for cross-cutting concerns that apply to all APIs or routes, such as security, logging, or traffic management.
When a plugin is scoped to a specific service or route, it only affects requests that are directed to that service or route. This allows you to add specific functionality or behavior to individual APIs or routes, without affecting other APIs or routes in the system. Scoped plugins are typically used for API-specific concerns, such as authentication, rate limiting, or transformation.
To add a plugin globally, you can add it to the http section in the Kong configuration file or use the Kong Admin API to add the plugin with no service or route ID specified.
6. You must specify a route for a plugin?
Yes, that is correct. In Kong, when you add a plugin, you must specify a route for the plugin to associate it with a specific API route.
A route is a collection of rules used to match incoming requests to a specific upstream service. Each route is associated with a specific service and defines which requests should be forwarded to that service based on criteria such as the request path or headers.
When you add a plugin to a route, it only affects the requests that match that route. This allows you to add specific functionality or behavior to individual API routes, without affecting other routes in the system.
To add a plugin to a route, you can use the Kong Admin API or the Kong Dashboard.
7. are plugins applied globally?
Yes, plugins can be applied globally in Kong. When a plugin is added globally, it is applied to all incoming requests that pass through the Kong API Gateway. This means the plugin will affect all services and routes configured in Kong. Global plugins are typically used for cross-cutting concerns that apply to all APIs or routes, such as security, logging, or traffic management.
Adding a plugin globally allows you to apply the same functionality or behavior to all APIs or routes in your Kong installation without having to add the plugin to each individual service or route. However, it is important to note that global plugins may not always be appropriate, especially if you have APIs with conflicting requirements or if you need to apply different configurations to different APIs. In these cases, you can use service-level or route-level plugins instead.
8. Which is a mandatory section of an OpenAPI specification?
The openapi section is a mandatory section of an OpenAPI specification. It is used to specify the version of the OpenAPI Specification that is being used and to provide basic information about the API, such as its title, version, and description.
9. Route, path, services, plugin, which of the following is a mandatory section of an OpenAPI specification?
The mandatory sections of an OpenAPI specification are:
openapi: This section specifies the version of the OpenAPI Specification being used, and it should always be the first section in the specification.
info: This section provides basic information about the API, such as its title, version, and description.
paths: This section defines the individual endpoints of the API and their operations.
10. What is the command to validate an OpenAPI specification?
inso lint is a command that is used to check an Insomnia Core workspace for potential issues and best practices violations. Insomnia Core is a popular REST API client that allows developers to test and debug APIs. With inso lint, developers can use Insomnia Core workspaces to improve the quality and consistency of their API testing.
