Getting Started
Consider your use case
Knocknoc can ultimately act as an authentication portal for many use cases, depending on your groups of users and applications. To simplify the setup to begin with, it helps to consider a single application to put behind Knocknoc, and build it out from there. You can add applications once the authentication source is configured, and once user-testing is complete, you can update the firewall or reverse proxy to block users who aren't using Knocknoc.
Cloud or self-hosted server?
The answer will depend on a few factors. For example, if your LDAP authentication source is not on the internet, then of course you need self-hosted. Secondly, it may be easy or hard to get inbound public IP access to the Knocknoc server in your environment. Our cloud servers are deployable in under a minute, and have DNS records and inbound rules all configured for you. A self-hosted Knocknoc server may also suit you better for various security segmentation scenarios, or even Knocknoc on the LAN, which is great for SCADA or ICS systems.
Where will your agents run?
The Knocknoc agent connects out to the server on port 443/tcp, and maintains a secure web socket connection to manage your ACLS. The agent needs to live where it can reach the backend it is controlling, so for example an HAproxy Unix socket is going to need to be on the same machine, or a firewall ipset or API might require the agent to be deployed in a control plane firewall zone. Deploying agent is easy, and as long as you consider where in your network they live, you can strike a great balance between security and control.
Select your backends
The backend is a type of control mechanism, for example, and HAproxy unix socket, or an AWS security group script. The backend needs to be able to apply the change to your protected application instantly and idempotently. Knocknoc agents are resilient and will update ACLs on backends in a reliable fashion, however various backends have limitations. For example an AWS security group can only have 60 entries before you need a support ticket, so you may want to consider if that suits your use case. AWS is a complicated topic, so it really depends on where the configuration space as to how your backend performs.