[Container-tools] Security vs. Usability: atomic commands and permissions

[Muayyad AlSadi]

Question: how about using consul.io instead of etcd

Consul support access tokens to control kv

And then we have 600 file token in each user home.

If k8s api is HTTP then maybe can wrap it with apache mod_ldap or basic auth

I guess the access levels from lower to higher

Read only: monitor status, see dashboard and graph, get service ip...

Read container's logs
Access container's terminal/shell

Decrease/increase replication for n>0

Launch new apps in the namespace

Namespace owner can delete

All the above for was specific namespace. All of the above for all
namespaces.





On Thu, Mar 3, 2016, 3:35 AM Josh Berkus <jberkus at redhat.com> wrote:

> On 03/02/2016 05:16 AM, Brian (bex) Exelbierd wrote:
> > On 02/27/2016 03:15 AM, Josh Berkus wrote:
> >> Folks,
> >>
> >> So I'm testing the new atomicapp tutorial documentation, and one thing
> >> I'm running across as a major usability issue for Linux desktop
> >> developers is that most of the commands require sudo, and create files
> >> which are owned and editable only by root.  Which means that I can't
> >> easily pull, fork and modify Nulecule applications for my own use in my
> >> text editor of choice (Atom, for example).
> >
> > Could we clean this up by setting files we expect to be edited to being
> > owned by the user?  I realize that creates a secondary security issue,
> > but it would ease the workflow.  We aren't talking about a production
> > situation here ...
> >
> > Ideally it would be nice to see privileges only used where they are
> > really needed.
>
> What's the advantage to having any files owned by root on the user's own
> laptop, in their dev environment?
>
>
> --
> --
> Josh Berkus
> Project Atomic
> Red Hat OSAS
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20160303/32498fa0/attachment.htm>