Security

The Oracle Backend for Microservices and AI has the following security characteristics:

All access to the database is done using the Mutual Transport Layer Security (mTLS) database wallet. The user name, password, and URL are stored in Kubernetes secrets.
Accessing most dashboards can only be done using port-forwarding, the exceptions are the ServiceOps Center and Grafana, which can be accessed through the load balancer using TLS and appropriate authentication. The passwords for the dashboards are provided by the installer or autogenerated and stored in Kubernetes secrets.
The only “public” exposure is the Apache APISIX Gateway (note that the dashboard is not exposed publicly), the ServiceOps Center and Grafana.
Services deployed to the platform are not exposed through the Apache APISIX Gateway automatically. If you want to expose the service through the gateway, you must define a route in the Apache APISIX dashboard. APISIX Gateway Documentation
The deployed platform services are using using self-signed certificates.
A customer application can only access services running in the platform using the Apache APISIX Gateway. APISIX Gateway Documentation
The customer application can be secured using Spring Security (for example, Spring OAuth 2.0 Resource Server). An external authorization server is recommended (for example Okta or Auth0).
Oracle Backend for Microservices and AI provides an authorization server which is an engine to authenticate and authorize requests to various components in Oracle Backend for Microservices and AI. The end user can manage users using REST Endpoints. AuthZ Server Documentation
Oracle Backend for Microservices and AI contains HashiCorp Vault to secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets, and other sensitive data. HashiCorp Vault Documentation

Transport Layer Security

The Oracle Backend for Microservices and AI is deployed with a sample self-signed certificate for Transport Layer Security (TLS). This results in an “Accept Risk” message when accessing the ServiceOps Center or Grafana web user interfaces and the sample TLS certificate should not be used for production deployments.

Updating the TLS Certificate

Ensure your Domain Name System (DNS) entry points to the IP address for the public load balancer. You can check this address with this command, the address in the EXTERNAL-IP field is the public load balancer address:
```
kubectl -n ingress-nginx get svc ingress-nginx-controller
```
Obtain a new TLS certificate. In a production environment, the most common scenario is to use a public certificate that has been signed by a certificate authority.

Create a new Kubernetes secret in the ingress-nginx namespace. For example:

kubectl -n ingress-nginx create secret tls my-tls-cert --key new-tls.key --cert new-tls.crt

Modify the service definition to reference the new Kubernetes secret by changing the service.beta.kubernetes.io/oci-load-balancer-tls-secret annotation in the service configuration. For example:

kubectl patch service ingress-nginx-controller -n ingress-nginx \
    -p '{"metadata":{"annotations":{"service.beta.kubernetes.io/oci-load-balancer-tls-secret":"my-tls-cert"}}}' \
    --type=merge