
Obtain a New Set of Secrets
If a user suspects that their secret or Kerberos keytab has been compromised, they should
contact an administrator to get a new set of secrets assigned.
The following shows an administrator using the
usm-recreate-secret
to assign a new set of
Mesos and Kerberos credentials to the user
bob
.
#
usm-recreate-secret bob
Secrets are stored in the NFS shared directory
/security/secrets
. The
/security
directory
is sub-divided into per-tenant directories as well, so there may be a directory
called
/security/
mytenant
/secrets
. When users are members of tenants, their secrets are
created initially in
/security/secrets
then linked to the tenant specific directories. On any
given tenant, the tenant directory is mounted as
/security
so
/security/secrets/
secret-file
has the same path both on physical nodes and on
tenant VMs, but only the secrets belonging to users who are tenant members are visible in the
tenant VM.
For more information, refer to the
usm-recreate-secret
man page.
Restarting Mesos After Syncing Users and Recreating New Secrets
The secrets for Mesos are registered with the Mesos configuration, requiring a restart of Mesos to pick up new
secrets. This is an intrusive operation, because restarting Mesos will interrupt running Mesos jobs, so it is done as
a manual step. After running
usm-sync-users
or
usm-recreate-secret
, wait for an appropriate
maintenance window and run
urika-stop -s mesos_custer
then
urika-start -s mesos_custer
to
restart Mesos.
TIP: Secrets of the '
marathon'
, '
spark'
, and '
haproxy
' accounts are not managed by the Urika-GX
secret manager commands. Refer to
Modify the Secret of a Mesos Framework
on page 256 if the secrets
of Urika-GX service-level Mesos secrets (such as
marathon
,
haproxy
, etc.) are compromised.
7.7
Guidance on LDAP Forwarding
Linux Authentication/Authorization
The Urika-GX cluster generally relies on LDAP to make user authentication and basic Linux authorization data
available to physical nodes and to the tenant VM. Urika-GX ships with a local LDAP server running on
login1
,
with a minimal set of users needed for sanity testing. If the local LDAP is examined or edited with an LDAP
browser, it is important to note that the two organizational units that contain standard posix user and posix group
information are the
ou=users
and
ou=groups
trees located under
dc=urika,dc=com
. In addition, the
ou=crayusers
organizational unit also lies in the same location. This unit should not be modified. It contains the
Urika-GX authorized users list, and is manipulated using the
ux-tenant-add-user
,
ux-tenant-remove-
user
,
ux-tenant-restrict
, and
ux-tenant-relax
commands. See
Authentication and Authorization
page 175 for more information.
Security
S3016
208