API Rule
The apirule.gateway.kyma-project.io CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format the API Gateway Controller listens for. To get the up-to-date CRD and show the output in the yaml format, run this command:
kubectl get crd apirules.gateway.kyma-project.io -o yamlSample custom resource
This is a sample custom resource (CR) that the API Gateway Controller listens for to expose a service. This example has the rules section specified which makes the API Gateway Controller create an Oathkeeper Access Rule for the service.
- v1beta1
- v1alpha1
This table lists all the possible parameters of a given resource together with their descriptions:
| Field | Mandatory | Description |
|---|---|---|
| metadata.name | YES | Specifies the name of the exposed API. |
| spec.gateway | YES | Specifies the Istio Gateway. |
| spec.host | YES | Specifies the service's communication address for inbound external traffic. If only the leftmost label is provided, the default domain name will be used. |
| spec.service.name | NO | Specifies the name of the exposed service. |
| spec.service.namespace | NO | Specifies the Namespace of the exposed service. |
| spec.service.port | NO | Specifies the communication port of the exposed service. |
| spec.rules | YES | Specifies the array of Oathkeeper access rules. |
| spec.rules.service | NO | Services definitions at this level have higher precedence than the service definition at the spec.service level. |
| spec.rules.service.name | NO | Specifies the name of the exposed service. |
| spec.rules.service.namespace | NO | Specifies the Namespace of the exposed service. |
| spec.rules.service.port | NO | Specifies the communication port of the exposed service. |
| spec.rules.path | YES | Specifies the path of the exposed service. |
| spec.rules.methods | NO | Specifies the list of HTTP request methods available for spec.rules.path. |
| spec.rules.mutators | NO | Specifies the array of Oathkeeper mutators. |
| spec.rules.accessStrategies | YES | Specifies the array of Oathkeeper authenticators. The supported authenticators are oauth2_introspection, jwt, noop, allow. |
CAUTION: If
serviceis not defined at spec.service level, all defined rules must haveservicedefined at spec.rules.service level, otherwise the validation fails.
Additional information
When you fetch an existing APIRule CR, the system adds the status section which describes the status of the VirtualService and the Oathkeeper Access Rule created for this CR. This table lists the fields of the status section.
| Field | Description |
|---|---|
| status.apiRuleStatus | Status code describing the APIRule CR. |
| status.virtualServiceStatus.code | Status code describing the VirtualService. |
| status.virtualService.desc | Current state of the VirtualService. |
| status.accessRuleStatus.code | Status code describing the Oathkeeper Rule. |
| status.accessRuleStatus.desc | Current state of the Oathkeeper Rule. |
Status codes
These are the status codes used to describe the VirtualServices and Oathkeeper Access Rules:
| Code | Description |
|---|---|
| OK | Resource created. |
| SKIPPED | Skipped creating a resource. |
| ERROR | Resource not created. |