Assessing Alpine linux in terms of security & support

sunhux
sunhux used Ask the Experts™
on
Our apps architect recommends  Alpine Linux for our
microservices/container environment.

Some time back, a patch management vendor told us
that patching for Alpine can't be managed by Satellite
or BigFix  ie we have to manually download & patch.

Q1:
is the above true or is there something like 'yum' in
RHEL to patch Alpine.

Q2:
Also, there's no CIS hardening benchmark nor any
docs that standardize what to harden for Alpine.

Q3:
Architect further points out that Alpine is the most
secure & efficient Linux to use for microservices;
is this true?  Does Alpine has good development
team that constantly check for vulnerabilities &
release advisories/patches (at least like RHEL)?

https://alpinelinux.org/about/
https://en.wikipedia.org/wiki/Alpine_Linux

Q4:
Where can I view past Alpine's CVEs/vulnerabilities
list & how can we assess how good are support
for Alpine?  Don't want a case where we log a
case for support & there's lack of response &
no solution
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Author

Commented:
From cyber perspective, I have concerns below:

a) As Alpine is rare, how many agents esp SIEM agents (Splunk,
    Alienvault, Trustwave/Spiderlabs) could install on it or this
    is irrelevant as it's the Base OS (we use RHEL) that matters?

b) in terms of virtual patching, I may want to use Trendmicro
    Deep Security but DS agents dont install on Alpine or we
    just need to install on Base OS & not the Container instances
    /image?

c) Possibly other agents like backup (or this doesn't matter as
    we backup the image?) & other tools that we may want to
    install agents in future??

d) Refer to the Wiki link above: each Alpine release lasts only
    about 2 years, very short lifecycle while RHEL (or CentOS
   as well) lasts 4-5 years usually: so we'll have to keep tech
   -refreshing Alpine every 2 years or is tech-refreshing
   Alpine in container environment is a trivial task?

e) Anyone has encountered penetration (blackbox or greybox
    or apps pentest) in Alpine environment & how easy it is to
    fix?  With an endpoint IPS, I can close many XSS & other
    findings more easily
David FavorFractional CTO
Distinguished Expert 2018
Commented:
Q1: is the above true or is there something like 'yum' in RHEL to patch Alpine.

You'll use the apk - Alpine Package Manger to manage your updates, so you can integrate apk into any other management system, just as you would with apt, yum, zypper, etc...

Q2: Also, there's no CIS hardening benchmark nor any docs that standardize what to harden for Alpine.

There is no difference between hardening Alpine + any other Linux Distro.

Hardening is hardening.

Use any hardening guide.

Note: Since Alpine is rarely encountered, uses a slightly more secure Kernel/libc, my guess is Alpine hacks are slightly less frequent than other Distros.

Q3a: Architect further points out that Alpine is the most secure....

See above.

Q3b: efficient Linux to use for microservices; is this true?

No. Linux is Linux.

Alpine might be theoretically faster, due to it's Kernel/libc approach. It's unlikely you could ever measure any speed difference.

Keep in mind the primary bottleneck on any system is network/disk I/O, which will is determined primarily hardware, so unless you're running a pure CPU app (like crypto currency mining), the only real speed gains come through optimizing your code to reduce physical I/O (caching).

Q3c: Does Alpine has good development
team that constantly check for vulnerabilities &
release advisories/patches (at least like RHEL)?

Yes. The dev team is stellar.

This said, I still use Ubuntu, because Ubuntu provides a far more sensible package management system than RedHat/Fedora/CentOS + packages release faster.

Using Alpine doesn't really buy you much additional benefit, because with Ubuntu you have more eyes on code than Alpine + the internal human resource management ensures Ubuntu will likely survive as primary developers retire or die. With Alpine, the legacy path is far more of a consideration.

Also since there's little no speed/security difference + software loaded into a Distro, like a LAMP Stack takes same disc space as Ubuntu, no real benefit... to me... which is why I stick with Ubuntu for money projects, even though I occasionally contribute to the Alpine project.

Q4: Where can I view past Alpine's CVEs/vulnerabilities
list & how can we assess how good are support
for Alpine?

Another reason I love Ubuntu is https://usn.ubuntu.com provides a clear log of all security notices, by date, with exact actions taken by Ubuntu to resolve the problem.

With Alpine, the only similar facility I've found is the many CVE reporting services.

RedHat provides https://access.redhat.com/security/security-updates which provides a similar facility to Ubuntu's.

Tip: None of these fix pages really matters much. To keep from getting hacked requires updating all machines + all containers, just as soon as any package updates release.

So... you can read about vulnerabilities (great cure for insomnia), or you can just install all package updates every morning, to avoid any hacker triggering any vulnerability.

Q5: Don't want a case where we log a case for support & there's lack of response & no solution.

My personal experience is my Alpine tickets are usually answered in a few minutes + if any patch is required, the fix is packaged + release in a few hours to days.

Alpine tends to provide fixes faster than Ubuntu or RedHat.

That said, because Alpine is newer than Ubuntu or RedHat, most of the fixes when Alpine was young, related to packaging problems Ubuntu + RedHat resolved years before.

At this point, I'd say almost all software patches release at about the same speed for Alpine, Ubuntu, RedHat, Suse, any other major Distro.
David FavorFractional CTO
Distinguished Expert 2018
Commented:
Suggestion: You haven't discussed why you're asking questions about Alpine.

Likely good if you open a 2nd question describing type of microservice (maybe that's why you're asking) you'll be developing.

Also the primary benefit you imagine Alpine might provide.

Hint: I run many local microservices for various projects.

I run Ubuntu at the machine level, then run each microservice in their own LXD container.

This allows me to scale easily (LXD clone container to another machine).

This also allows for easy machine maintenance, such as hardware failure or major software upgrade, which might crash a machine or make microservices unstable during updates. I do this by simply doing an LXD move of all containers of the machine under maintenance to another machine. Then move all containers back, after maintenance is complete.

When working with microservices, keep in mind just running the service is only one piece of the equation.

Maintenance + Scaling are usually the bigger questions/consideration.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

nociSoftware Engineer
Distinguished Expert 2018
Commented:
Q1: I think this answer #1: https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management

Q2: There is no CIS Script.. ?  CIS is a set of directives.  A script may need to be built for it.

Q3: It is small it doesn't start out with installing Everything (tm) like many others. which makes it an excellent choice for Docker or VM with tiny
       auditable footprints.
       Alpine made some basic smart choices (like PIE) where other Distro's in the past didn't and now have some legacy to lug around.
       For the answer on if they follow best practices etc. and follow security problems fixed in others and see if they were also fixed in Alpine..
       i.e. verify the trackrecord.

Q4: Here a story which reflects your questions: https://justi.cz/security/2018/09/13/alpine-apk-rce.html  (with happy end).
       (not a CVE to my knowledge).
      Releasenotes can tell a story:https://alpinelinux.org/posts/

Author

Commented:
Q1:
Ok, Alpine has apk.  Suppose we want something like Satellite or
only permit 1 Alpine to pull patches down into a repository & the
rest of the Alpine in our set-up gets their patches from this
repository, does Alpine offers anything of this nature?

Do we pay subscription to get Alpine support like the way we pay
subscription to RedHat & if so, is Alpine's support/subscription
 fee based on per Alpine endpoint?
nociSoftware Engineer
Distinguished Expert 2018
Commented:
Apk repositories:

If you rsync to one of these: https://mirrors.alpinelinux.org/  (marked with rsync)
you have your own inhouse REPO.

If you configure YOUR mirror during deployment then you have your own repository in house.
(running rsync or what ever fetch method you want regularly will keep you up to date).

The cost: the hardware you need to accomodate it.

This is the way you can help Alpine Linux development, aka to "pay" a fee for it: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Contribute

Author

Commented:
Item c  is quite crucial: regulators & auditors require PAM (eg: Cyberark,
Thycotic, TPAM) whenever there's privileged access.

Reckon the 3 PAM  I indicated above requires their agents to be installed
in the endpoint without which, it won't work or there's no agent required?
We won't get past our regulators (2 of them) & auditors without a PAM.
nociSoftware Engineer
Distinguished Expert 2018
Commented:
You will have to test this. If the claim is it will run in Linux then it can probably also run there.
If there are requirements like a specific version of some distro ... well things can shift.
It depends on the Agent and it's requirement.

Best would be to have requirements that are already API like things... Uses SSH  or LDAP or .... something with a well known & supported interface is best to have anyway.
David FavorFractional CTO
Distinguished Expert 2018

Commented:
As noci suggested, if you really require Alpine (you haven't explained why yet), you'll dig into each question by install Alpine + testing.

Author

Commented:
David, it's the apps architect's
recommendation n I'm still
brainstorming with him.

Have seen a site showing Intel's
CleanLinux offers best performance while Alpine
is below average relative to
other distros like Debian,
CentOS, Ubuntu
David FavorFractional CTO
Distinguished Expert 2018
Commented:
The point most people miss about Alpine is this.

Alpine, with no software installed has a smaller footprint than Ubuntu.

Once you start installing code like a LAMP Stack, there's no big win over saved space.

Tip: About app architecture, using Alpine may cause you massive amounts of extra cost + grief, because Alpine is rarely found in the wild.

This means developing an Alpine based app is great for your developer, as it will be very difficult for you to escape from this person's billing.

When I onboard a new client, our first conversation is about who will die first - my client or me.

I design all projects from the consideration of me dying first + client project living on, so for me personally... I use Alpine from time to time to keep up with Alpine's evolution.

And I would never, ever, ever suggest to a client we use Alpine for a project.

Note: There is no measurable difference in performance between any Linux Distro, per my above discussion.

Rule is this.

If your Application uses I/O (network or disk), then performance is determined by hardware + has zero to do with the Distro.

Even CPU bound applications, like crypto currency mining, you'd be hard pressed to find a measurable difference, because you'd be trying to measure very small units of resource usage.

Suggestion: Always start with the application (you haven't described your app yet), then hire someone very smart about optimizing I/O, which has zero to do with Distro + 100% to do with application coding.

Tip: This leads to another consideration, someone talking heavily about speed of Distros rather than code architecture... how best to say this...

Might be time to open another question here asking for suggestion about how each person might design your app. You will notice no discussion about Distro in the related answers... other than this...

I personally use Ubuntu LTS (5+ years support) because the package management is stellar, saving me many hours of time daily, across many projects.

Also, Ubuntu is supported every where, so I can alway install it.

The disk layout of config files makes more sense to me than other Distros.

In other words, I use Ubuntu for lowest number of hours/day required for Distro maintenance.

For code performance, I focus on code, not Distro.
Software Engineer
Distinguished Expert 2018
Commented:
I am with David on this.   Although i like basic distro's like Debian often better than derivatives. But this is my personal opnion.

Support availability should be first. The real secret to high performance code is "How to avoid doing work."
be smart at creating solution that can keep stuff in memory (avoiding IO) and ensure all IO is write IO for updates. f.e.

Hardware is key, and most things are EASIER "in Virtualized machines", not faster or better.   Running a database in a VM means all IO's need to be done twice.
(administrative work on the IO often is more work that the IO itself), so working smart is running a DB engine on bare metal..
David FavorFractional CTO
Distinguished Expert 2018

Commented:
noci actually said this more clearly than my rambling.

Support, to me, is always my first consideration which dictates I use Ubuntu.

If upstream support is flawed, this means project time/budget overruns occur, which is unacceptable with tightly controlled projects.

noci also provides clarity about I/O. If you use a VM based system of any kind, you'll do 2x or more I/O for every 1x I/O, which is a performance killer. This is why I only use LAMP stacks running in LXD containers, so all processes run at bare metal speed.

Still be best if you open a 2nd question describing your project specifics, asking for design suggestions.

Or hire 10x smart people for 1 hour of consulting. Have each person design your system for you. Roll in the best of all the design suggestion, into your final design.
David FavorFractional CTO
Distinguished Expert 2018

Commented:
You're welcome!

Tip: Whether you use Docker or LXD depends heavily on your application.

1) Microservices (with no persistent data across boots) use Docker.

2) Websites/Apps (requiring any persistent data across boots, like MariaDB/MySQL) use LXD.

If you violate this, for example trying to use Docker to implement a LAMP Stack, you must first redevelop some ad-hoc LXD like data management system for your SQL data files, which will be far more fragile than LXD.

Be sure to use the correct tech for your project.

Suggestion: Open another question... maybe titled... "LXD or Docker for project"... then describe your project + ask for design assistance.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial