hey <@U04UQ68083H>, what's the best way to secure ...
# ory-copilot
t
hey @chilly-king-10285, what's the best way to secure our docker compose suit for Ory so that our admin ui project for user management can securely interact with it?
b
A message from kapa.ai
To securely expose your Ory services (such as Ory Kratos, Hydra, or Keto) in a Docker Compose setup—especially for an admin UI handling user management—you should follow these best practices: 1. Do Not Expose Admin APIs Publicly Ory open-source servers (including Kratos and Hydra) do not have built-in access control for their admin APIs. Exposing these endpoints directly to the internet is a significant security risk. Only the public APIs should be accessible externally; admin APIs should be protected and accessible only from trusted networks or services [API access control](https://www.ory.sh/docs/self-hosted/operations/api-access-control) [Exposing administrative and public API endpoints](https://www.ory.sh/docs/hydra/self-hosted/production#exposing-administrative-and-public-api-endpoints). 2. Use an API Gateway or Ory Oathkeeper Place an API Gateway or [Ory Oathkeeper](https://github.com/ory/oathkeeper) in front of your admin APIs. Oathkeeper acts as an identity and access proxy, allowing you to define access rules and enforce authentication/authorization for sensitive endpoints. This ensures only your admin UI (or other trusted services) can interact with the admin APIs [API access control](https://www.ory.sh/docs/self-hosted/operations/api-access-control). 3. Network Segmentation in Docker Compose Configure your Docker Compose network so that admin APIs are only accessible within the internal Docker network. Your admin UI container can then securely communicate with Ory services, while external access is blocked. 4. Secure Secrets and Configuration Make sure to generate strong secrets for cookies and encryption, and never use default or insecure values in production. For example, update the 
kratos.yml
 with secure, randomly generated secrets and disable sensitive logging [Secure secrets](https://www.ory.sh/docs/kratos/guides/deploy-kratos-example#secure-secrets). 5. Enforce HTTPS Always use HTTPS (TLS) for all communication, especially for admin endpoints, to protect data in transit [Integrity and confidentiality](https://www.ory.sh/docs/security-compliance/gdpr#integrity-and-confidentiality). Example: Protecting Admin APIs with Oathkeeper - Run Ory Kratos and Oathkeeper in your Docker Compose setup. - Configure Oathkeeper to proxy requests to the Kratos admin API, applying access rules so only authenticated/authorized requests from your admin UI are allowed. - Do not expose the Kratos admin API port directly to the host network. This approach ensures your admin UI can securely interact with Ory services, while minimizing the attack surface and following Ory’s recommended security practices [Run Ory Kratos and the Ory Oathkeeper identity and access proxy](https://www.ory.sh/docs/kratos/guides/zero-trust-iap-proxy-identity-access-proxy#run-ory-kratos-and-the-ory-oathkeeper-identity-and-access-proxy). If you need more specific configuration examples, let me know your stack details!
t
Can I self-secure our implementation with our own oathkeeper? Can you show an example of an optimal docker-compose.yml to coordinate all?
@chilly-king-10285 Can I self-secure our implementation with our own oathkeeper? Can you show an example of an optimal docker-compose.yml to coordinate all?
b
A message from kapa.ai
Yes, you can self-secure your Ory implementation using your own Ory Oathkeeper instance. Oathkeeper acts as an identity and access proxy, allowing you to define access rules and enforce authentication/authorization for your Ory services, including protecting admin APIs from unauthorized access [API access control](https://www.ory.sh/docs/self-hosted/operations/api-access-control). Below is an example of an optimal
docker-compose.yml
setup that coordinates Ory Kratos and Oathkeeper, following best practices from the official documentation. This setup ensures that only trusted services (like your admin UI) can access the admin API, while all other traffic is routed and protected by Oathkeeper.
Copy code
yaml version: "3.7" services:   postgres-kratos:     image: postgres:12     environment:       - POSTGRES_USER=kratos       - POSTGRES_PASSWORD=secret       - POSTGRES_DB=kratos     networks:       - intranet    kratos-migrate:     image: oryd/kratos:<version-you-want>     depends_on:       - postgres-kratos     environment:       - DSN=<postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4>     volumes:       - type: bind         source: ./kratos         target: /etc/config/kratos     command: -c /etc/config/kratos/kratos.yml migrate sql -e --yes     networks:       - intranet    kratos:     image: oryd/kratos:<version-you-want>     depends_on:       - kratos-migrate     environment:       - DSN=<postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4>     ports:       - "4433:4433" # Public API       # Do NOT expose 4434 (admin) to host!     volumes:       - type: bind         source: ./kratos         target: /etc/config/kratos     networks:       - intranet     command: serve -c /etc/config/kratos/kratos.yml --dev --watch-courier    oathkeeper:     image: oryd/oathkeeper:<version-you-want>     depends_on:       - kratos     ports:       - "4455:4455" # Proxy port       - "4456:4456" # Oathkeeper API (optional, for debugging)     command: serve proxy -c "/etc/config/oathkeeper/oathkeeper.yml"     environment:       - LOG_LEVEL=debug     volumes:       - ./oathkeeper:/etc/config/oathkeeper     networks:       - intranet    admin-ui:     image: your-admin-ui-image     environment:       # Configure your admin UI to use Oathkeeper as the gateway to Kratos admin API     networks:       - intranet  networks:   intranet:
Key points: - The Kratos admin API (
4434
) is only accessible within the Docker network (
intranet
), not exposed to the host. - Oathkeeper proxies and protects access to Kratos (and other Ory services if needed). - Your admin UI communicates with Kratos admin API through Oathkeeper, which enforces your access rules. You will need to configure Oathkeeper with appropriate access rules and authenticators to ensure only authorized requests from your admin UI are allowed to reach the admin API [Configure and deploy](https://www.ory.sh/docs/oathkeeper/configure-deploy) [Zero Trust with Access Proxy guide](https://www.ory.sh/docs/kratos/guides/zero-trust-iap-proxy-identity-access-proxy#run-ory-kratos-and-the-ory-oathkeeper-identity-and-access-proxy). For a full example including Oathkeeper and Kratos configuration files, see the official guides: - [Zero Trust with Access Proxy guide](https://www.ory.sh/docs/kratos/guides/zero-trust-iap-proxy-identity-access-proxy#run-ory-kratos-and-the-ory-oathkeeper-identity-and-access-proxy) - [Oathkeeper WebSocket proxy example](https://www.ory.sh/docs/oathkeeper/guides/proxy-websockets) If you need a sample Oathkeeper config or access rules, let me know!