Skip to content
This repository has been archived by the owner on May 6, 2020. It is now read-only.

feat(controller): add deis certs:transfer endpoint #1221

Open
deis-admin opened this issue Jan 19, 2017 · 10 comments
Open

feat(controller): add deis certs:transfer endpoint #1221

deis-admin opened this issue Jan 19, 2017 · 10 comments

Comments

@deis-admin
Copy link

From @stuszynski on October 7, 2015 15:7

Hi,

This project is quite new to me but it seems that I'll be hanging around here for a while. ;) I encounter some strange issue and I'm not sure if this is a desired behavior.

We have several users on our deis platform that including 3 admins (with superuser privilages). If some of them add application certificate it can't be listed or removed by another admin.

First admin (who added certificates):

$ deis certs:list
Common Name                Expires
-------------------------  ----------------------
*.myawesomecert.com                  2016-08-24T23:59:59UTC
www.yolo.io                          2020-05-30T10:48:38UTC

Second admin:

$ deis certs:list
No certs
$ deis perms:list --admin
{
  "count": 3,
  "previous": null,
  "results": [
    {
      "username": "admin1",
      "is_superuser": true
    },
    {
      "username": "admin2",
      "is_superuser": true
    },
    {
      "username": "admin3",
      "is_superuser": true
    }
  ],
  "next": null
}

I figure out that if I'll add any another certificate (second admin) it will be visible in cers:list but only by me and a first admin will not see this certificate as well. Anyway all certificates will be correctly rendered on routers.

Unfortunately I couldn't find anything suspicious in the api code. I tested it on 1.8.0 and 1.9.1 platform and I also updated a client to 1.11.0 with no luck.

What do you think of it? Is this a bug or some sort of user/owner relation for application certs that I'm not aware of?

Copied from original issue: deis/deis#4576

@deis-admin
Copy link
Author

From @bacongobbler on October 7, 2015 15:36

This is intentional by design. Administrators have global access to all resources, but viewing objects (such as other users' applications and certificates) are masked. Whether or not that's intentional by design is a discussion we can have for v2, but we have to maintain that for v1.

If the other administrator tried deis certs:remove www.yolo.io, would that work? If not then that would be a bug.

@deis-admin
Copy link
Author

From @szymonpk on October 7, 2015 16:43

@bacongobbler it's rather poor solution :( What if admin we'll leave project? Is there any way to move certificates to other admin?

@deis-admin
Copy link
Author

From @bacongobbler on October 7, 2015 17:14

You could manually do so through the following:

$ deisctl dock controller
# python manage.py shell
>>> from api.models import *
>>> from django.contrib.auth import User
>>> olduser = User.objects.get(username="admin1")
>>> newuser = User.objects.get(username="admin2")
>>> for cert in Certificate.objects.filter(owner=u):
>>>   cert.owner = newuser
>>>   cert.save()
>>>   exit()

At the moment, there is no way to transfer certificates through the API.

@deis-admin
Copy link
Author

From @stuszynski on October 8, 2015 10:53

@bacongobbler Thanks for a snippet!

I double check that. I can't remove certificate via certs:remove added by another admin and also I didn't get any error in process.

$ deis certs
No certs

$ deis certs:remove www.yolo.io
Removing www.yolo.io... done

$ echo $?
0

# On deis router
bash-4.3# ls /etc/ssl/deis/certs/
www.yolo.io.cert

also that other admin can still list this certificate.

@deis-admin
Copy link
Author

From @sstarcher on January 12, 2016 17:43

So... we need to share a common admin due to this defect since we have no desire to have a single person in charge of any one task. I'm in agreement with @szymonpk this is a defect. As far as we are concerned no single user owns anything in our system and admins need to be able to manage everything.

One single person should not be the only one who can make a change and shared users with shared passwords are bad.

@jmccarty3 @nyxcharon

@deis-admin
Copy link
Author

From @szymonpk on January 13, 2016 6:52

@sstarcher As poor man solution I can suggest having additional Deis profile with shared admin user and use it like this: DEIS_PROFILE=sharedadmin deis.... (or you can wrap it with alias). As a little 'richer' poor man solution - we've custom web panel for various tasks and we're adding certs functionality there (since we've awesome webdev around ;-)).

@deis-admin
Copy link
Author

From @sstarcher on January 13, 2016 13:43

@szymonpk you should open source that ;)

@deis-admin
Copy link
Author

From @bacongobbler on February 25, 2016 7:0

@stuszynski @sstarcher does the title change reflect the feature you guys would like to see? I know we have deis apps:transfer so I don't see a reason why we couldn't implement this feature (likely in v2 unless someone feels like backporting) :)

@deis-admin
Copy link
Author

From @sstarcher on February 25, 2016 12:58

@bacongobbler What I expected from my initial use was for all admins or people with access to the project to be able to see the certs. What happened is only the initial creator could see the certs.

@Cryptophobia
Copy link
Contributor

This issue was moved to teamhephy/controller#36

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants