RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1462403 - custodia-ipa-plugin: KeyError: u'kra_server_server'
Summary: custodia-ipa-plugin: KeyError: u'kra_server_server'
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: custodia
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Petr Čech
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks: 1467660
TreeView+ depends on / blocked
 
Reported: 2017-06-17 07:21 UTC by Petr Čech
Modified: 2017-08-22 07:33 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1467660 (view as bug list)
Environment:
Last Closed: 2017-08-07 10:37:42 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Petr Čech 2017-06-17 07:21:41 UTC 
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'
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.
Comment 3 Martin Babinsky 2017-06-20 12:27:23 UTC 
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.
Comment 4 Christian Heimes 2017-06-20 13:51:43 UTC 
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.
Comment 10 Martin Babinsky 2017-07-10 14:47:00 UTC 
Upon further investigation on FreeIPA side I discovered a different issue with the config reporting code and that is that it does not enforce contract imposed by input/output parameter specification, i.e. an empty attribute was returned even if the 'kra_server_server' parameter is marked as optional and as such is not returned in the response if it is not present.

I have fixed this in FreeIPA upstream, but in general the client code should not rely on the presence on optional attributes in the JSON-RPC response and better test for membership (or catch KeyErrors) when processing it.

I am sorry to cause an inconvenience on your side by this.
Comment 12 Martin Kosek 2017-08-07 10:29:57 UTC 
RHEL-7.4 is now already GA, should the bug be closed as ERRATA?
Comment 13 Petr Čech 2017-08-22 07:33:50 UTC 
It is already closed, thanks. I just remove the flag needinfo.
Note You need to log in before you can comment on or make changes to this bug.