Multi-Cloud applications are a core business for us here at meshcloud. Therefore, we also put some effort into the integration of several OpenStack locations using federation. After all, meshcloud is a federation of public clouds.
Recently, we re-assessed the federated authentication with the OpenStack CLI client using v3.12.0 against a Mitaka OpenSource environment. On the identity provider (IdP) side, we use Keycloak’s OIDC capabilities.
Password vs. Token Auth
We look at two options for federated authentication at the command line:
v3oidcpassword
Auth Method: User/Password credentials of Identity Provider
Pros:
- Static RC file, no refresh of token necessary
- RC file itself does not provide any access without password
Cons:
- Password necessary at CLI
- Manual Keystone Token Issuing
- Risk of using password at CLI
v3oidcaccesstoken
Auth Method: OIDC Java Web Token (JWT) issued by Identity Provider
Pros:
- Direct bearer usage, no password necessary (=> automation)
- Keystone token automatically issued
Cons:
- Access not secured if RC file is leaked
So, depending on your use case you might prefer the one over the other. In any case, you prepare an appropriate RC file (=a shell script setting the environment variables to configure the openstack cli).
v3oidcpassword
Environment
If you want to use the OpenStack command line using your Identity Provider’s user/password credentials, create an RC file like this:
# clear unnecessary settings
unset OS_PROJECT_NAME
unset OS_REGION_NAME
# set needed settings
export OS_INTERFACE="public"
# insert here Keystone auth url for the specific cloud
export OS_AUTH_URL="https://keystone.example.com:5000/v3"
export OS_IDENTITY_PROVIDER="keycloak-idp"
export OS_PROTOCOL="oidc"
export OS_CLIENT_ID="meshfed-oidc"
# use any value for client secret if we use a public oidc client
export OS_CLIENT_SECRET="ac2aa84b7685-5ffb-9f1d"
export OS_DISCOVERY_ENDPOINT="https://idp.example.org/auth/realms/meshfed/.well-known/openid-configuration"
export OS_IDENTITY_API_VERSION="3"
export OS_AUTH_TYPE="v3oidcpassword"
# insert here the user name to authenticate
export OS_USERNAME="username"
# this is the local openstack project id
export OS_PROJECT_ID="27a7e59d391d55c6cf4ead12227da57e"
# set password by querying user
export OS_PASSWORD=""
echo "Please enter your Meshcloud Password: "
read -sr OS_PASSWORD_INPUT
export OS_PASSWORD=$OS_PASSWORD_INPUTYou need the OS_AUTH_URL refers to the Keystone auth endpoint of the cloud you want to access. OS_IDENTITY_PROVIDER is the label you created with openstack identity provider create when creating the identity provider within OpenStack. OS_CLIENT_ID is the name of the OIDC client configured at the IdP. Now it is important that you set OS_CLIENT_SECRET even if you have not a confidential client configured at the IdP because the OpenStack cli expects it to be present. If you use a „public“ OIDC client configuration, just put in a dummy value. OS_DISCOVERY_ENDPOINT sets the metadata endpoint for the IdP server. It saves you to set a lot of other config options (it’s already more than enough, isn’t it?).
Of course, we set OS_AUTH_TYPE to v3oidcpassword. The username of your IdP account goes to OS_USERNAME and OS_PROJECT_ID needs the local project id of your OpenStack project you want to access. See below if you do not know the project id. The remainder of the script is to ask you for your password on the command line, but you can also set OS_PASSWORD directly.
Command line usage
Now get to your prompt and source the RC file:
➜ source v3oidcpassword.sh
Please enter your OpenStack Password:After you entered your password, you need to issue a Keystone token and you can start issuing commands:
➜ cli-test openstack token issue
+------------+----------------------------------+
| Field | Value |
+------------+----------------------------------+
| expires | 2017-08-23T13:37:33+0000 |
| id | d6d222ccfba24bfa9c85d5baa039f110 |
| project_id | 5edf2f36ac334618a614731a146a60ec |
| user_id | 7ca9d31f46da4e52b44ac263745e4a77 |
+------------+----------------------------------+
(openstack) router create test
(openstack) router list
+--------------+------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------+------+--------+-------+-------------+-------+----------------------------------+
| d1907a5b-... | test | ACTIVE | UP | False | False | 5edf2f36ac334618a614731a146a60ec |
+--------------+------+--------+-------+-------------+-------+----------------------------------+If you would like to see the projects you have access to, e.g. to get the right project id for the RC file, issue:
openstack federation project listAnd you will see a list of projects you can access with your federated account. Pretty cool, huh? 🙂
v3oidcaccesstoken
If you don’t want to deal with passwords at the command line, v3oidcaccesstoken is an alternative to authenticate with OpenStack using the JWT issued by the IdP. A JWT is an encoded JSON data set containing identity and authorization information. You can decode them using jwt.io.
Environment
export OS_INTERFACE="public"
export OS_IDENTITY_API_VERSION=3
export OS_AUTH_TYPE="v3oidcaccesstoken"
export OS_AUTH_URL="https://keystone.example.com:5000/v3"
export OS_IDENTITY_PROVIDER="keycloak-idp"
export OS_PROTOCOL="oidc"
export OS_ACCESS_TOKEN="eyJhbGciOiJSUzI1NiIsIn..........9uFum6TWK_69OAbM3RjFbjiDvg"
export OS_PROJECT_ID="27a7e59d391d55c6cf4ead12227da57e"You see the configuration is much simpler as lots of information is contained in the JWT access token (it usually is a very long string, we just cut it here for display purposes). Sourcing this file enables you to issue a Keystone token (and hence do work in the project) as long as the OIDC JWT is valid.
Command line usage
Source the file, then start working:
➜ source v3oidcaccesstoken.sh
➜ openstack server list
+--------------------------------------+------------------+--------+---------------------------------------------+------------------------------------------+------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+------------------+--------+---------------------------------------------+------------------------------------------+------------+
| 6447040b-cc8c-46f3-91a8-949aa1744981 | flinktest | ACTIVE | test=192.168.106.25, 212.56.234.218 | ubuntu-xenial-16.04_softwareconfig_0.0.2 | gp1.medium |
...You see it is much shorter in application and does not require to set a password.
Using CLI access with meshcloud
To make multi-cloud access easier, meshcloud already prepares the necessary RC files for your project. Just go to the Panel and select the project and location you want to access. Choose „CLI Access“ and you find the RC files for download. Source them into your shell and you’re ready to go.
Outlook
The v3oidcpassword and v3oidcaccesstoken are very helpful to use CLI access on federated OpenStack clouds. However, for automated access (e.g. scripts) neither of them is perfect – either you have to store a password or you have only a limited access token. The OIDC standard has a solution called Offline Tokens. Those are refresh tokens (ie. tokens used to re-issue a new access token without credential re-authentication) that never expire. They are intended for automatic procedures who need access to protected resources. Upon access, the bearer requests a fresh (short-living) access token using the Offline Token. The major advantage is that Offline Tokens can be revoked at the IdP site. A revoked Offline Token cannot be used to acquire new access tokens and hence access is disabled. So you still have a central veto when providing decentral access without passwords.
Soon, meshcloud will provide an integrated CLI client that makes accessing multiple clouds and projects more convenient and helps you speed up with your open-source multi-cloud experience. Stay tuned :).
Questions
Any questions left? How are you using federated authentication with OpenStack? Let us know. We’re looking forward to hear from you.