Support IPsec Certificate-based Authentication

[xliuxu]

Describe what you are trying to solve
The current Antrea IPSec support can only use preshared shared key (PSK) authentication with static manually created keys. This is too limited for serious use in enterprise networks.

Describe the solution you have in mind
OVS supports authenticating tunnel endpoints using x509 version 3 certificates. Antrea only needs to manage the certificates and load them to each Node. OVS toolkits will be responsible for monitoring and configuring the IKE daemon.

Describe how your solution impacts user flows

Describe the main design/architecture of your solution

1. Antrea Controller creates self signed root CA for IPsec and watches for CertificateSigningRequest with signer name antrea.io/antrea-agent-ipsec-tunnel
2. Each Antrea Agent create CSR with its own Node name. For clusters enabled BoundServiceAccountTokenVolume (enabled by default since Kubernetes 1.21) there will be extra fields to identify the Pods added by the Kubernetes API server.

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
 name: k8s-node-control-plane-ipsec-xxx
spec:
  extra:
    authentication.kubernetes.io/pod-name:
    - antrea-agent-5vjjf
    authentication.kubernetes.io/pod-uid:
    - 3ede5c83-b42a-4f64-a325-a91d3db09d72
  request: <PEM encoded CSR>
  signerName: antrea.io/antrea-agent-ipsec-tunnel
 usages:
  - ipsec tunnel

3. Antrea Controller verify the CSR by checking:

• the usage matches ["ipsec tunnel"].
• the decoded CSR in .spec.request has valid CN and SAN name.
• the Pod in .spec.extra is on the Node which the CSR requests.

4. Antrea Controller Approve and Sign the CSR. Antrea should not auto-approve the CSR for clusters not enabled BoundServiceAccountTokenVolume and also provide a switch to disable the AutoApprove` feature for security concerns.
5. Antrea Agent saves the CSR and configure OVS bridge to load certificates. To trigger reloading of ovs-monitor-ipsec daemon, the cert and key file names should be changed during certificate rotation.

# ovs-vsctl set Open_vSwitch . \
other_config:certificate=/etc/ipsec.d/certs/k8s-node-control-plane-cert-xxx.pem \
other_config:private_key=/etc/ipsec.d/private/k8s-node-control-plane-privkey-xxx.pem \
other_config:ca_cert=/etc/ipsec.d/cacerts/cacert.pem

6. Antrea Agent should rotate the signed certificates when the certificate is about to expire.

Test plan
TBD

Additional context
Slides for the proposal.

[jianjuns]

The proposal looks good to me. We should support user provided CA cert too.

A question: I assume uthentication.kubernetes.io/pod-name is auto populated by K8s, not added by antrea-agent right?

[xliuxu]

For user-provided CA, do we need user to provide the CA and also privatekey in order to sign certificates for Nodes? Or do you mean that user only need to provide the CA certificate, and they will also need to sign and manage certificates for all Nodes. If the latter applies, the potential issue is that we may need users to save all the certificates and private keys for Nodes to one single Secret as antrea-agent Daemonset need to mount them.

authentication.kubernetes.io/pod-name will be added by the apiserver during creation and it is immutable. it requires BoundServiceAccountTokenVolume feature gate to be enabled (enabled by default since 1.21).

I think we can add an option called ApprovePolicy, and it will have three options:

1. Never - antrea-controller will never auto approve the CSR created by antrea-agents.
2. IfAuthenticated - antrea-controller will leverage the BoundServiceAccountTokenVolume to verify CSR by the extra field.
3. Always - antrea-controller will only check for necessary constraints for IPsec certificates. It will auto-approve the CSR no matter whether BoundServiceAccountTokenVolume is enabled or not, as long as the CSR for IPsec is valid.

And I am not sure whether IfAuthenticated is a good name. Any suggestion would be appreciated.

[jianjuns]

I meant users to provide CA private key.

The three options sound good to me. "IfAuthenticated" - how about ValidateAgentPodName.

[xliuxu]

Thank you @jianjuns. btw, do we need a feature gate for this feature? Or should we replace the PSK-based verification completely?

[jianjuns]

We should keep PSK as it is a simpler solution. Need to look at your code to know if we need a feature gate for cert or not. But at least we need a way to decide which mode to use (e.g. based on if PSK or CA cert provided or not, default to cert).