Make Connect sidecar of Operator

[villesau]

Summary

Making Connect sidecar of the Operator would limit the Connect scope to inside pod, which in turn would mean that no ports would need to be opened outside the pod. This would limit the risk of misconfiguration and exposing the Connect too widely accidentally.

Use cases

When you only need Connect for serving Operator. For example I only need Connect to serve the Operator so I don't need the endpoints to be exposed to anything else. I would sleep my nights better if it were abstracted away.

Proposed solution

Implement a possibility to make Connect sidecar of Operator

Is there a workaround to accomplish this today?

Not that I know.

E: Actually this is exactly the reason why I'd rather keep the Connect as a sidecar for the Operator: #65 It is too easy to expose the endpoints to external world.

[jillianwilson]

Thanks for reaching out. I think there are use cases for both running 1Password Connect run from outside of the Connect Operator or as a separate sidecar so I think it might be nice to have an optional field in the helm chart to deploy as a sidecar rather than in a separate pod. We will look into potentially implementing this in the future.

[villesau]

Yes an option would probably make sense in this case since if the connect is used for something else than the operator only, sidecar is not that good option. But if it is used solely for the operator, it would isolate the connect well and thus reducing the risk factor significantly as well as make the setup simpler.