## 4.3.1.2.3.2  Exposing and Securing Workloads with extAuth
Expose and secure your workload using the extAuth access strategy.
## Prerequisites
- You have the Istio and API Gateway modules added. See Adding and Deleting a Kyma Module [page 3157].
- You have installed curl and kubectl . Y ou have configured kubectl to communicate with your Kyma runtime instance. See Access a Kyma Instance Using kubectl [page 2018].
- You have a deployed workload.
##  Note
To expose a workload using APIRule in version v2 , the workload must be a part of the Istio service mesh. See Enabling Istio Sidecar Proxy Injection [page 1783].
- You have set up your custom domain . Alternatively, you can use the default domain of your Kyma cluster and the default Gateway kyma-system/kyma-gateway .
##  Note
Because the default Kyma domain is a wildcard domain, which uses a simple TLS Gateway, it is recommended that you set up your custom domain for use in a production environment.
```
 Tip To learn what the default domain of your Kyma cluster is, run the following command: kubectl get gateway -n kyma-system kyma-gateway -o jsonpath='{.spec.servers[0].hosts}'
```
- You have a JSON Web Token (JWT). See Get a JWT .
## Context
Learn how to expose and secure services using APIGateway Controller and OAuth2.0 Client Credentials flow. For this purpose, this task uses oauth2-proxy with an OAuth2.0 complaint authorization server supporting OIDC discovery. APIGateway Controller reacts to an instance of the APIRule custom resource (CR) and creates an Istio VirtualService and AuthorizationPolicy with action type CUSTOM .
## Procedure
1. Replace the placeholders and define the oauth2-proxy configuration for your authorization server.
<!-- image -->
```
config: clientID: {CLIENT_ID} clientSecret: {CLIENT_SECRET} cookieName: "" cookieSecret: {COOKIE_SECRET} extraArgs: auth-logging: true cookie-domain: "{DOMAIN_TO_EXPOSE_WORKLOADS}" cookie-samesite: lax cookie-secure: false force-json-errors: true login-url: static://401 oidc-issuer-url: {OIDC_ISSUER_URL} pass-access-token: true pass-authorization-header: true pass-host-header: true pass-user-headers: true provider: oidc request-logging: true reverse-proxy: true scope: "{TOKEN_SCOPES}" set-authorization-header: true set-xauthrequest: true skip-jwt-bearer-tokens: true skip-oidc-discovery: false skip-provider-button: true standard-logging: true upstream: static://200 whitelist-domain: "*.{DOMAIN_TO_EXPOSE_WORKLOADS}:*" EOF
```
2. To install oauth2-proxy with your configuration, use oauth2-proxy helm chart :
3. Register oauth2-proxy as an authoriation provider in the Istio module.
4. To expose and secure the Service, create the following APIRule:
```
kubectl create namespace oauth2-proxy helm repo add oauth2-proxy https://oauth2-proxy.github.io/manifests helm upgrade --install oauth2-proxy oauth2-proxy/oauth2-proxy -f values.yaml -n oauth2-proxy
```
```
kubectl patch istio -n kyma-system default --type merge --patch '{"spec": {"config":{"authorizers":[{"name":"oauth2-proxy","port":80,"service":"oauth2proxy.oauth2-proxy.svc.cluster.local","headers":{"inCheck":{"include":["xforwarded-for", "cookie", "authorization"]}}}]}}}'
```
```
cat <<EOF | kubectl apply -f apiVersion: gateway.kyma-project.io/v2alpha1 kind: APIRule metadata: name: {APIRULE_NAME} namespace: {APIRULE_NAMESPACE} spec: hosts: - {SUBDOMAIN}.{DOMAIN_TO_EXPOSE_WORKLOADS} service: name: {SERVICE_NAME} port: {SERVICE_PORT} gateway: {GATEWAY_NAME}/{GATEWAY_NAMESPACE} rules: - extAuth: authorizers: - oauth2-proxy methods: - GET path: /*
```
5. To call the endpoint, send a GET request to the exposed Service:
- a. To call the endpoint, send a GET request to the exposed Service:
```
curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_TO_EXPOSE_WORKLOADS}/headers
```
You get the 401 Unauthorized response code.
- a. Now, access the secured workload using the correct JWT.
```
curl -ik -X GET https://{SUBDOMAIN}.{DOMAIN_TO_EXPOSE_WORKLOADS}/headers -header "Authorization:Bearer {ACCESS_TOKEN}"
```
You get the 200 OK response code.