opa
opa copied to clipboard
Update the security docs to recommend binding to 127.0.0.1 / localhost
The docs on security already make use of --addr 127.0.0.1
or localhost in some of the examples provided, but does not mention why this is a good practice that should generally be followed for any non-public OPA deployment.
Unless explicitly configured, OPA will bind to the 0.0.0.0 interface, which allows the OPA server to be exposed to services running outside of the same machine. While this by itself is not insecure in a trusted environment — exposing OPA to the outside world also requires the ports to be actively made open on the machine, and likely also the same procedure to be done in a gateway layer above — it is clear that there are OPA deployments in the wild where this has not been accounted for (thanks @magnologan!). We should update the docs to reflect the best practice here, and recommend binding to the localhost interface unless exposing OPA to remote services is desired, in which case the other recommendations of the security document applies (require authentication, etc).
In addition to better documentation, it's been suggested that we print something informative on server start unless any --addr
has been provided — i.e. when the default value has been picked. While this might be somewhat annoying, it's easily fixed by doing the right thing. Naturally, we'll want to make sure all our docs are updated to follow our own advice.
Hey @anderseknert! :wave:
Are you thinking of editing this section:
By default, OPA ignores insecure HTTP connections when TLS is enabled. To allow insecure HTTP connections in addition to HTTPS connections, provide another listening address with --addr. For example:
And adding something like what you wrote above after/before?
Unless explicitly configured, OPA will bind to the 0.0.0.0 interface, which allows the OPA server to be exposed to services running outside of the same machine. While this by itself is not insecure in a trusted environment — exposing OPA to the outside world also requires the ports to be actively made open on the machine, and likely also the same procedure to be done in a gateway layer above
Then maybe mention something here if you have chosen not to bind to localhost
?
I could also look at the second point of printing something on server start but I've not checked the whereabouts of that yet :smile:
Let me know how I can chip in on this!
Thanks Peter! I would not add it to the TLS section as this is relevant regardless of TLS or not. Maybe a new section called "Interface binding" or something like that? And an example showing what do use, e.g:
--addr localhost:8181
Hey Team! :wave:
This could be a silly question but how would I trigger this error here
Unless I misunderstand, you can leave out --addr
and still use opa run --server
and if you set the flag but give it no values you get Error: flag needs an argument: --addr
:thinking:
Sorry if it's a dumb question :sweat:
It's not a dumb question. You probably can't reach that condition — it's likely just a defenseive measure should that change anytime in the future.
Hey Team :wave:!
What do you think about doing something like this for the server message?
if rt.Params.Addrs != nil {
for _, addr := range *rt.Params.Addrs {
if addr == ":8181" {
rt.logger.Warn("You are not binding to localhost")
}
}
}
The message itself is just a placeholder for now :sweat_smile: if there is a much more elegant or more thoughtful way of doing this please LMK!
Thanks! :+1:
That would only check for binds on port 8181 though :) I.e. you could still do ":9999"... but you're thinking that if you did, you've at least made a conscious decision to do so=
That would only check for binds on port 8181 though :) I.e. you could still do ":9999"... but you're thinking that if you did, you've at least made a conscious decision to do so=
That's what I was thinking yeah, I saw it more as a guardrail in case you forgot to do --addr
would the alternative be that unless its specifically localhost
it should add a warning? or, it could just always print a warning :thinking: as an FYI so many options :smile:
I think what you have is fine. Just needs a better message :)
I think what you have is fine. Just needs a better message :)
Nice! I will do a bit of work on this today or tomorrow and open it up for review :rocket:
Hey @anderseknert :wave:
LMK what do you think?
I also added a couple of test cases which I hope are okay :smile:
The warning message will point to the newly created section in the docs, but let me know if I should change it up or reword it a bit to suit your liking :+1:
Thanks as always!