Bug 1467660 - custodia-ipa-plugin: KeyError: u'kra_server_server' [NEEDINFO]
custodia-ipa-plugin: KeyError: u'kra_server_server'
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: custodia (Show other bugs)
25
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Simo Sorce
Fedora Extras Quality Assurance
:
Depends On: 1462403
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-04 09:19 EDT by Jan Pazdziora
Modified: 2017-12-12 05:26 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1462403
Environment:
Last Closed: 2017-12-12 05:26:41 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jpazdziora: needinfo? (cheimes)


Attachments (Terms of Use)

  None (edit)
Description Jan Pazdziora 2017-07-04 09:19:47 EDT
+++ This bug was initially created as a clone of Bug #1462403 +++

Description of problem:


Version-Release number of selected component (if applicable):
-------------------------------------------------------------
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.4 Beta (Maipo)

# on server
$ rpm -qa | grep ipa
ipa-server-common-4.5.0-17.el7.noarch
libipa_hbac-1.15.2-47.el7.x86_64
python-iniparse-0.4-9.el7.noarch
python2-ipalib-4.5.0-17.el7.noarch
python2-ipaserver-4.5.0-17.el7.noarch
sssd-ipa-1.15.2-47.el7.x86_64
ipa-common-4.5.0-17.el7.noarch
ipa-client-4.5.0-17.el7.x86_64
ipa-server-dns-4.5.0-17.el7.noarch
ipa-client-common-4.5.0-17.el7.noarch
python-libipa_hbac-1.15.2-47.el7.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python2-ipaclient-4.5.0-17.el7.noarch
ipa-server-4.5.0-17.el7.x86_64

# on client
$ rpm -qa | grep ipa
ipa-client-common-4.5.0-17.el7.noarch
python-ipaddress-1.0.16-2.el7.noarch
python2-ipalib-4.5.0-17.el7.noarch
python-custodia-ipa-0.5.0-1.el7.noarch
python-iniparse-0.4-9.el7.noarch
libipa_hbac-1.15.2-47.el7.x86_64
python2-ipaclient-4.5.0-17.el7.noarch
sssd-ipa-1.15.2-47.el7.x86_64
ipa-client-4.5.0-17.el7.x86_64
ipa-common-4.5.0-17.el7.noarch
python-libipa_hbac-1.15.2-47.el7.x86_64

$ rpm -qa | grep custodia
python-custodia-ipa-0.5.0-1.el7.noarch
custodia-0.5.0-1.el7.noarch
python-custodia-0.5.0-1.el7.noarch


How reproducible:
-----------------
Setup IPA server with KRA.
Setup IPA client.
Setup custodia and run it.

Steps to Reproduce:
-------------------
# we assume:
# (IPA server) algol.persei.dev
# (IPA client) mirach.persei.dev

1) install ipa (on server)
$ yum -y --nogpgcheck install ipa-server ipa-server-dns bind bind-dyndb-ldap


2) setup ipa (on server)
$ ipa-server-install -a myspulin -p myspulin \
                   --domain=persei.dev \
                   --realm=PERSEI.DEV \
                   --hostname algol.persei.dev \
                   --setup-dns --no-forwarders -U

# enable ports on firewall
$ firewall-cmd --permanent \
               --add-service={ntp,http,https,ldap,ldaps,kerberos,kpasswd,dns}
$ firewall-cmd --reload


3) install ipa client (on client)
$ yum -y --nogpgcheck install ipa-client ipa-admintools bind bind-dyndb-ldap sssd

4) setup ipa client (on client)
# we need have IPA server as nameserver in /etc/resolv.conf
$ ipa-client-install

5) Custodia installation (on client)
# Create user and group
$ useradd -U -r ug-custodia

# Create directories
$ sudo mkdir /etc/custodia /var/lib/custodia /var/log/custodia /var/run/custodia
$ sudo chown ug-custodia:ug-custodia /var/lib/custodia /var/log/custodia /var/run/custodia
$ sudo chmod 750 /var/lib/custodia /var/log/custodia

# Create service account and keytab
$ kinit admin
$ ipa service-add custodia/$HOSTNAME
$ ipa service-allow-create-keytab custodia/$HOSTNAME --users=admin
$ mkdir -p /etc/custodia
$ ipa-getkeytab -p custodia/$HOSTNAME -k /etc/custodia/ipa.keytab
$ chown ug-custodia:ug-custodia /etc/custodia/ipa.keytab

# The IPA cert request plugin needs additional permissions
$ ipa privilege-add \
    --desc="Create and request service certs with Custodia" \
    "Custodia Service Certs"
$ ipa privilege-add-permission \
    --permissions="Retrieve Certificates from the CA" \
    --permissions="Request Certificate" \
    --permissions="Revoke Certificate" \
    --permissions="System: Modify Services" \
    "Custodia Service Certs"

# for add_principal=True
$ ipa privilege-add-permission \
    --permissions="System: Add Services" \
    "Custodia Service Certs"
$ ipa role-add \
    --desc="Create and request service certs with Custodia" \
    "Custodia Service Cert Adminstrator"
$ ipa role-add-privilege \
    --privileges="Custodia Service Certs" \
    "Custodia Service Cert Adminstrator"
$ ipa role-add-member \
    --services="custodia/$HOSTNAME" \
    "Custodia Service Cert Adminstrator"

# Create /etc/custodia/ipa.conf
# /etc/custodia/ipa.conf

$ cat <<EOF > /etc/custodia/ipa.conf
[global]
debug = true
makedirs = true

[auth:ipa]
handler = IPAInterface
keytab = /etc/custodia/ipa.keytab
ccache = FILE:${rundir}/ccache

[auth:creds]
handler = SimpleCredsAuth
uid = root
gid = root

[authz:paths]
handler = SimplePathAuthz
paths = /. /secrets

[store:vault]
handler = IPAVault

[store:cert]
handler = IPACertRequest
backing_store = vault

[/]
handler = Root

[/secrets]
handler = Secrets
store = vault

[/secrets/certs]
handler = Secrets
store = cert
EOF


6) install KRA (on server)
$ ipa-kra-install

7) check KRA (on client)
$ ipa server-show algol.persei.dev | grep KRA

8) run custodia (on client)
$ custodia /etc/custodia/ipa.conf & echo $! >> custodia.pid


Actual results:
---------------
# Step 8 produce:
2017-06-17 07:57:54 - custodia                         - Custodia debug logger enabled
2017-06-17 07:57:54 - custodia                         - Custodia audit log: /var/log/custodia/audit.log
2017-06-17 07:57:54 - custodia                         - Custodia instance <main>
2017-06-17 07:57:54 - custodia                         - Config file(s) ['/etc/custodia/ipa.conf'] loaded
2017-06-17 07:57:54 - IPAInterface-[auth:ipa]          - Kerberos principal 'custodia/mirach.persei.dev@PERSEI.DEV'
2017-06-17 07:57:54 - IPAInterface-[auth:ipa]          - IPA server 'algol.persei.dev': IPA server version 4.5.0. API version 2.228
Traceback (most recent call last):
  File "/sbin/custodia", line 9, in <module>
    load_entry_point('custodia==0.5.0', 'console_scripts', 'custodia')()
  File "/usr/lib/python2.7/site-packages/custodia/server/__init__.py", line 138, in main
    _load_plugins(config, cfgparser)
  File "/usr/lib/python2.7/site-packages/custodia/server/__init__.py", line 126, in _load_plugins
    plugin.finalize_init(config, cfgparser, context=None)
  File "/usr/lib/python2.7/site-packages/custodia/plugin.py", line 367, in finalize_init
    self._attach_store(config, cfgparser, context)
  File "/usr/lib/python2.7/site-packages/custodia/plugin.py", line 356, in _attach_store
    store_plugin.finalize_init(config, cfgparser, context=self)
  File "/usr/lib/python2.7/site-packages/custodia/ipa/vault.py", line 70, in finalize_init
    servers = response[u'result'][u'kra_server_server']
KeyError: u'kra_server_server'


Expected results:
-----------------
Trouble-free start of custodia.

--- Additional comment from Martin Babinsky on 2017-06-20 14:27:23 CEST ---

This is partly a regression on FreeIPA side: previously, if either there was no server providing the queried role (KRA server in this case) or the requesting principal had no read privilege on the master's service entries the API returned the attribute with empty value.

In ipa 4.5 it does not return the attribute at all. I will fix the IPA part but on the custodia side you have to be sure the custodia/ principal has read access to the service entries (cn=<service_name>,cn=<master_fqdn>,cn=masters,cn=ipa,cn=etc,$SUFFIX).

This should be covered by "Read IPA masters" permission or "IPA Masters Readers" privilege. Petr can you verify that adding these for custodia principal allows it to retrieve the u'kra_server_server' attribute? If not, we will have to provide some privilege regarding reading masters' service entries.

--- Additional comment from Christian Heimes on 2017-06-20 15:51:43 CEST ---

We decided to address the issue in custodia now. It's less risk because it's just a three lines change in custodia. Also custodia.ipa is a tech preview and not production code.

I have added a workaround to upstream https://github.com/latchset/custodia.ipa/commit/f7fac6cf5834f4b3101b8f5ee29b84a5cae468ff and released custodia.ipa 0.4.2 with that fix. A new build of custodia 0.3.1 for RHEL 7.4 is undergoing testing now.

--- Additional comment from Christian Heimes on 2017-06-26 18:42:33 CEST ---

custodia-0.3.1-4.el7 has been released and tagged into RHEL 7.4.
Comment 1 Jan Pazdziora 2017-07-04 09:20:44 EDT
I see the same problem on Fedora 25 with custodia-0.3.1-1.fc25.noarch. It breaks our tests.

Please backport (well, forward-port) the fix from RHEL 7.4 to Fedora 25+.
Comment 2 Martin Babinsky 2017-07-10 10:48:54 EDT
JFTR, as per https://bugzilla.redhat.com/show_bug.cgi?id=1467660#c10 the fix should be made on custodia side, the previous behavior of the vaultconfig-show was actually buggy and not consistent with the rest of API commands in IPA.
Comment 3 Fedora End Of Life 2017-11-16 14:06:11 EST
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 4 Jan Pazdziora 2017-11-29 09:47:01 EST
Christian, do you know if we consider this fixed in Fedora 26+?

Incidently, I do not see that custodia-0.3.1-1.fc25.noarch (mentioned in comment 1) in Fedora koji so I'm not really sure where I took that one ...
Comment 5 Christian Heimes 2017-11-30 06:17:49 EST
No idea, I have to investigate the issue. It's going to take until next week as I'm swamped with other tasks.
Comment 6 Fedora End Of Life 2017-12-12 05:26:41 EST
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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