Bug 1275379 - kubernetes apiserver missing capabilities to open port 443 [NEEDINFO]
kubernetes apiserver missing capabilities to open port 443
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kubernetes (Show other bugs)
7.1
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jan Chaloupka
atomic-bugs@redhat.com
: Extras
Depends On:
Blocks: 1287902
  Show dependency treegraph
 
Reported: 2015-10-26 13:41 EDT by Robert Rati
Modified: 2016-02-16 11:30 EST (History)
6 users (show)

See Also:
Fixed In Version: kubernetes-1.2.0-0.2.alpha1.git8632732.el7_2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-16 11:30:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jchaloup: needinfo? (eparis)


Attachments (Terms of Use)

  None (edit)
Description Robert Rati 2015-10-26 13:41:30 EDT
Description of problem:
Kubernetes upstream ansible installer adds capabilities to the kube-apiserver to allow the secured setup to run on port 443.  Specially, the installer uses:

setcap cap_net_bind_service=ep /usr/bin/kube-apiserver

This capability will be lost when the rpm packages are upgraded.  Ideally the kube-apiserver binary in the rpm would shipped with the capability or the functionality provided via the systemd unit file.

Version-Release number of selected component (if applicable):
kubernetes-master-1.0.3-0.1.gitb9a88a7.el7

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 Robert Rati 2015-10-26 13:48:24 EDT
[13:33:12] <walters> I think systemd is the correct and secure way to delegate binds to privileged ports to any application, containerized or not
[13:35:38] <eparis> walters: so what's the answer on a non-systemd system, ya' know?
[13:36:52] <walters> one can carry the traditional "start as root, bind, then drop privs" code as a build-time option and just disable it on systemd systems
Comment 7 Jason Brooks 2015-11-12 13:46:07 EST
(In reply to Robert Rati from comment #0)
> Description of problem:
> Kubernetes upstream ansible installer adds capabilities to the
> kube-apiserver to allow the secured setup to run on port 443.  Specially,
> the installer uses:
> 
> setcap cap_net_bind_service=ep /usr/bin/kube-apiserver
> 
> This capability will be lost when the rpm packages are upgraded.  Ideally
> the kube-apiserver binary in the rpm would shipped with the capability or
> the functionality provided via the systemd unit file.

Another issue is that on atomic hosts, /usr is read-only, so ansible can't make this change, anyway. It works w/ fedora atomic, because fedora's kubernetes pkg gets CAP_NET_BIND_SERVICE in its spec file:

http://pkgs.fedoraproject.org/cgit/kubernetes.git/commit/?id=857cddbff129e70655e68ced08df11a931cb39e6

It's my understanding that systemd won't work to set the capabilities. I'm thinking about using ansible to copy the kube-apiserver service file over to /etc and change it to run as root...
Comment 8 Colin Walters 2015-11-13 11:20:29 EST
(In reply to Jason Brooks from comment #7)

> It's my understanding that systemd won't work to set the capabilities. 

Not sure what that means.  My suggestion is to use a kubernetes-apiserver-443.socket unit, so that systemd listens on the socket, then activates the apiserver and passes the socket down.  No privileges would then be required for apiserver.

More info:
http://freedesktop.org/wiki/Software/systemd/DaemonSocketActivation/
and `man systemd.socket`.
Comment 9 Jason Brooks 2015-11-13 11:22:58 EST
(In reply to Colin Walters from comment #8)
> (In reply to Jason Brooks from comment #7)
> 
> > It's my understanding that systemd won't work to set the capabilities. 
> 
> Not sure what that means.  My suggestion is to use a
> kubernetes-apiserver-443.socket unit, so that systemd listens on the socket,
> then activates the apiserver and passes the socket down.  No privileges
> would then be required for apiserver.

Got it, I thought you were talking about specifying "Capabilities=" in the unit file.

> 
> More info:
> http://freedesktop.org/wiki/Software/systemd/DaemonSocketActivation/
> and `man systemd.socket`.
Comment 10 Colin Walters 2015-11-15 08:57:59 EST
See also https://github.com/kubernetes/contrib/pull/242
Comment 16 errata-xmlrpc 2016-02-16 11:30:17 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0184.html

Note You need to log in before you can comment on or make changes to this bug.