Creating certificates locally or remote

[cemo]

What are difference about creating certificates on remote or locally?

I am asking this because I am considering to use statefulset with a storage. PKI related stuff can be created on local machine but certificates might be created on remote. What do you think?

[pieterlange]

There is some ongoing discussion on how to manage the PKI itself (see also here)

There is nothing stopping you from mounting stateful storage into /etc/openvpn/pki and managing the PKI from there, but i feel like that's a bad practice as the openvpn server itself doesn't need to access the CA keys.

Related is #7 where i'd like to support a more flexible (user friendly) way of issueing configs based on certificate signing requests, so the openvpn operator never needs to see the private key of the user. This can already be done manually but is not for the faint of heart.

[pieterlange]

I'm considering introducing 2 deployment modes.

• Current: externally managed PKI
• Fully managed PKI inside of kubernetes. Difficulties here:
  • Distributing client certificates securely: do we want client to provide certificate signing requests (secure) or generate their private key for them? (arguably insecure)
  • Encrypting the CA key: an interactive prompt for the CA password seems inevitable. This means a lot of automation goes out of the window.
  • Integrating with HSM's
  • Vault seems feasible
  • Other HSM's are pricey

Thoughts welcome

[zambien]

OK, so I think that other comment here was meant to go in this issue.

Vault is certainly feasible and I'm a big fan of HashiCorp in general. FWIW Vault is not an HSM, https://www.vaultproject.io/intro/vs/hsm.html, but it can integrate with one and in many cases is enough.

I think scoping this is very important. I have experience doing infrastructure as code deployments for HashiCorp Vault with Terraform. So making that happen is possible but may be scope creep.

Do you have a slack channel for further discussion or would you prefer to discuss here?

[zambien]

BTW, a buddy of mine just pointed this out.

https://www.terraform.io/docs/providers/tls/index.html

It may solve your use case.

[cemo]

@pieterlange

We are working on a workflow with my colleague, @pasali, to provide a remote workflow based on your project. In this workflow we will have a 2 docker container.

The first one will be named vpn-operator which will be responsible for initializing pki infrastructure, creating and revoking client certificates. The certificates and pki folder will be synched into the mounted EBS volume or on a similar persistent storage on Kubernetes. The second one will be your docker container.

We are also using a chatops bot to communicate with vpn-operator container.

We have developed a working prototype right now and will start to use this week.

[pieterlange]

Nice to hear! How do you intend to work around the issues mentioned earlier in https://github.com/pieterlange/kube-openvpn/issues/31#issuecomment-305347469?

Keep in mind you can only mount an EBS volume once, so you can't scale the openvpn container anymore after moving to that.

[cemo]

so you can't scale the openvpn container

We will have two different kind of container. vpn-operator will be a single container. It will just create certificates and will talk with bots. On the otherside vpn container can be scalable since it just mounts k8s configmaps and does not require pki and client certificates. This sounds doable, isn't it?

Distributing client certificates securely: do we want client to provide certificate signing requests (secure) or generate their private key for them? (arguably insecure)

Our bot is providing certificate by a private message to user. This scenario can be extended to some points where an oauth mechanism can be introduced. In case a revoking operation, configmaps are reloaded by vpn-operator.

Encrypting the CA key: an interactive prompt for the CA password seems inevitable. This means a lot of automation goes out of the window.

Encrypting would be CA key will be cool but it is already stored plain in our local boxes. For our demo system, we have completed removed it. But considering other alternatives as you suggested.

What do you think?

[pieterlange]

I like the UX aspect of provisioning users over chat, but this is a highly sensitive step in suppling the client credentials.

Hope you plan to publish it and if so, looking forward to the code.