Enable weave network encryption

[edulop91]

1. Describe IN DETAIL the feature/behavior/change you would like to see.

We would like to enable weave's network encryption capabilities for intra cluster communications. This weave feature is documented at

• https://www.weave.works/docs/net/latest/concepts/encryption/
• https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/

Reading over previous kops issues I see that Feature request: ability to configure weave (#1171) is inconclusive. Any updates on this front? I also see that #2600 merged. Presumably this would not be that different a change.

2. Feel free to submit an issue documenting a design supporting your feature request.

From the weave documentation looks like we'd only need a password flag in its configuration to enable encryption. Perhaps this could be a boolean config exposed to users. If true, a random key is generated by kops, stored similar kops secrets, and injected into the weave config files. Another alternative is having users provide a key.

Upgrading existing clusters could be problematic/require downtime.

Happy to contribute time towards this feature. Wondering if there's anything else surrounding #1171 or this particular feature development-wise that I should be aware of before doing so.

Thanks!

[chrislovecnm]

A kops secret which is used in the template would be perfect. I think you have a good example to use.

I am open to using a random key as well.

We probably want to store the data in a k8s secrets which is populated in the weave manifest

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[chrislovecnm]

/remove-lifecycle stale

[chrislovecnm]

Here are the tasks:

1. create a new secret for weave, either manual secret or automatically
2. update the API much like this PR add support for changing the weave peer connection limit #4398, with a value for weave encryption

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[ameena007]

/reopen

[ameena007]

This is a required security feature.

[brosander]

This would be really nice to have.

[ApsOps]

@chrislovecnm Hi. I'm working on this, but I'm not sure how to create a k8s secret from a kops secret. Any pointers?

We probably want to store the data in a k8s secrets which is populated in the weave manifest

Also, do we need to create another secret type for this? Currently I see only these 4 types are available:

  dockerconfig     Create a docker config.
  encryptionconfig Create an encryption config.
  keypair          Create a secret keypair.
  sshpublickey     Create a ssh public key.

[thedarkfalcon]

Is part of developing a toggle for this to have the status easily visible somewhere? I think I have enabled this feature manually, but the only way I have found to check the weave encryption status is to run weave directly on one of the master/slaves. I thought the whole point of kops is to remove direct access/management of the infrastructure/machines, this would be the first time I have had to access the machines directly.

Edit:
Nevermind, I found how to check the network encryption via kubectl to remotely exec a weave command to dump status to screen. E.g.

$ kubectl exec -n kube-system weave-net-1jkl6 -c weave -- /home/weave/weave --local status

        Version: 2.0.1 (up to date; next check at 2017/07/10 13:49:29)

        Service: router
       Protocol: weave 1..2
           Name: 42:8e:e8:c4:52:1b(host-0)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 3
    Connections: 3 (2 established, 1 failed)
          Peers: 3 (with 6 established connections)
 TrustedSubnets: none

        Service: ipam
         Status: ready
          Range: 10.32.0.0/12
  DefaultSubnet: 10.32.0.0/12

[kampka]

Sorry, I forgot to link this.
This issue was actually fixed in #5441

A word of warning, I have no tried to migrate a production cluster yet and I doubt it will work without downtime.

[thedarkfalcon]

I don't know why, but my weavenet never seems to come when I enable encryption with a secret I just added. My flow is: create the secret, apply Weaveworks K8s with password-secret
But the pods fail to spin up. If I delete the secret and recreate it, the pods start to spin up and everything functions as expected..

[kampka]

@thedarkfalcon well, that is hard for me to diagnose.
I hope you noticed the warning about creating the secret on an already running, unencrypted cluster?
A weave-kube pod with encryption configured cannot connect to a pod that does not have encryption enabled and vice versa (which is kind of the point of doing this).

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[thedarkfalcon]

Just for anyone else that finds this thread via google. My problem was that the filename of the secret actually seemed to matter. Even though I was giving the secret a name, the file that the secret was being read from seemed to have an affect of the secrets data.

I was initially creating the secret from a Jenkins secret file - which receives a random name when it is exposed to the Jenkins workspace. This secret was then being added to the cluster, however the metadata or something with the Kubernetes secret was wrong due to the input filename.. When I was deleting the secret and manually recreating it, I was using the expected filename.

I troubleshooted all this by being bad and just dumping secrets to screen and saw the discrepancy.