Expose a Function with an API Rule
This tutorial shows how you can expose your Function to access it outside the cluster, through an HTTP proxy. To expose it, use an APIRule custom resource (CR) managed by the in-house API Gateway Controller. This controller reacts to an instance of the APIRule CR and, based on its details, it creates an Istio VirtualService and Oathkeeper Access Rules that specify your permissions for the exposed Function.
When you complete this tutorial, you get a Function that:
- Is available on an unsecured endpoint (handler set to
noop
in the APIRule CR). - Accepts the
GET
,POST
,PUT
, andDELETE
methods.
NOTE: To learn more about securing your Function, see the Expose and secure a workload with OAuth2 or Expose and secure a workload with JWT tutorials.
TIP: Read also about Function’s specification if you are interested in its signature,
event
andcontext
objects, and custom HTTP responses the Function returns.
Prerequisites
This tutorial is based on an existing Function. To create one, follow the Create a Function tutorial.
NOTE: Read about Istio sidecars in Kyma and why you want them. Then, check how to enable automatic Istio sidecar proxy injection. For more details, see Default Istio setup in Kyma.
Steps
Follow these steps:
- Kyma CLI
- kubectl
- Kyma Dashboard
Export these variables:
Click to copyexport DOMAIN={DOMAIN_NAME}export NAME={FUNCTION_NAME}export NAMESPACE={NAMESPACE_NAME}NOTE: The Function takes the name from the Function CR name. The APIRule CR can have a different name but for the purpose of this tutorial, all related resources share a common name defined under the NAME variable.
Download the latest configuration of the Function from the cluster. This way you will update the local
config.yaml
file with the Function's code.Click to copykyma sync function $NAME -n $NAMESPACEEdit the local
config.yaml
file and add the apiRules schema for the Function at the end of the file:Click to copyapiRules:- name: {FUNCTION_NAME}service:host: {FUNCTION_NAME}.{DOMAIN_NAME}rules:- methods:- GET- POST- PUT- DELETEaccessStrategies:- handler: noopApply the new configuration to the cluster:
Click to copykyma apply functionCheck if the Function's code was pushed to the cluster and reflects the local configuration:
Click to copykubectl get apirules $NAME -n $NAMESPACECheck that the APIRule was created successfully and has the status
OK
:Click to copykubectl get apirules $NAME -n $NAMESPACE -o=jsonpath='{.status.APIRuleStatus.code}'Call the Function's external address:
Click to copycurl https://$NAME.$DOMAIN