Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Download

The user guide for the iControl REST interface in BIG-IP, version 11.6.0.

This download is secured and you do not have access. Please login or register to view downloads.
Comments on this Download
Comment made 05-Sep-2014 by Martin Klein 1
As far as i understand it is still not possible to set the default route domain for an administrative partition via the rest-api ?
0
Comment made 28-Aug-2015 by Andrew Le 104
Yes, you can set route-domain using iControl REST in v12.0.0 and lower. Here's an example syntax: $ curl -sk -u admin:admin -H 'Content-Type: application/json' -X POST https://<bigip ip>/mgmt/tm/net/route-domain -d '{&quot;name&quot;:&quot;/Part1/4&quot;}' |python -m json.tool</bigip>
-2
Comment made 22-Mar-2017 by g.clark

RBAC commands are not correct in the guide. Here are the commands that work, plus expected output:

1) CREATE THE USER:

tmos# create auth user iCR-user01 partition-access add { all-partitions { role manager } } password p4ssw0r6

2) GET THE SELFLINK FOR THE RESPECTIVE USER:

*** In this example my admin user has a username of "admin" and a password of "password" ***

bash# curl -kv -u admin:password https://localhost/mgmt/shared/authz/users

*** A section of my returned results are below ***

{"name":"iCR-user01","displayName":"iCR-user01","generation":3,"lastUpdateMicros":1490126667852098,"kind":"shared:authz:users:usersworkerstate","selfLink":"https://localhost/mgmt/shared/authz/users/iCR-user01"}

3) COPY VALUE OF SELFLINK

"selfLink":"https://localhost/mgmt/shared/authz/users/iCR-user01"}

4) ADD USER ACCOUNT TO THE ROLE WITH PATCH METHOD

curl -kv -u admin:password -H "Content-Type: application/json" -X PATCH -d '{ "userReferences":[{"link":"https://localhost/mgmt/shared/authz/users/iCR-user01"}] }' https://localhost/mgmt/shared/authz/roles/iControl_REST_API_User

5) TEST WITH A GET REQUEST (I also created a iCR-user02 user so that I could compare)

curl -kv -u iCR-user01:p4ssw0r6 -X GET https://localhost/mgmt/tm/ltm

200 response with data

curl -kv -u iCR-user02:iCR-user02 -X GET https://localhost/mgmt/tm/ltm

401 Error
3
Comment made 27-Apr-2017 by Antonio Varni 129

g.clark - thanks so much! I was trying to troubleshoot why the F5 kubernetes controller wasn't working (crashing on unexpected 401) (k8s-bigip-ctlr) and thankfully found your comment.

This works great.

0
Comment made 31-May-2017 by Jonas Bergsten 0

Worked like a charm. Abandoned my attempts the last time when I couldn't get it to work properly, thanks to this it's working as intended!

0
Comment made 12-Jun-2017 by Sukhjit Singh 0

Hi,

I have checked the RBAC configuation would give user access to all the resource. Can you please suggest a way to customize the resourceMask with restMethod to limited resources only.

Thanks!

0
Comment made 01-Aug-2017 by brad 376

Concluding that there is some 'inner circle' who enjoy knowing how all this works. For the common folk and those outside that circle the information is not correct if it is even available (sense some frustration)?

It is great that some have gotten some use of this and there certainly is demand and interest here for using REST API, but getting an account defined that is read-only and with only access to required resources seems to be elusive.

And we use other brands/vendors productions with REST API and it isn't near as impossible to use. And tokens don't expire in 8 hours and you can specify without all this complicated POST and PATCH business to get things off the ground..

Has someone, perhaps, come up with a user manager - Postman or otherwise - that can be used to define and maintain users for the iControl REST API?

Thanks so much.. it would be valuable to so many....

0
Comment made 22-Jan-2018 by Stephan Manthey 3803

Thanks to Kent for the description. Role based access is essential for one of my clients.
The mechanism used to work fine even through BIG-IQ as a REST API proxy up to BIG-IQ v5.3.
It was just required to extend the "resourceMask" i.e. as follows:
"resourceMask":"/mgmt/shared/resolver/device-groups/cm-bigip-allDevices/devices/8a6bd41c-3b72-4b0f-9099-cafc2e8aa1f4/rest-proxy/mgmt/tm/ltm/virtual/*"
In the example above a prefix of "/mgmt/shared/resolver/device-groups/cm-bigip-allDevices/devices/8a6bd41c-3b72-4b0f-9099-cafc2e8aa1f4/rest-proxy/" was inserted to address a BIG-IP device (specified by UUID of "8a6bd41c-3b72-4b0f-9099-cafc2e8aa1f4") managed by BIG-IQ after permitting REST API proxy funktionality per device via patching "{"properties":{"isRestProxyEnabled":true}}".

Unfortunately now this seems to be broken or not longer supported in BIG-IQ v5.4. Anyone out there got it working with BIG-IQ v5.4?

0
Comment made 22-Jan-2018 by Stephan Manthey 3803

To answer Brad´s question. Yes, it takes a bit to work through the authorization schema. Below you will find a short summary of "resourceMask" and "restMethod" tuples to specify privileges generally or specifically on object level.

###################
# virtuals

GET     ./mgmt/tm/ltm/virtual                                           # List all virtual servers (cannot list a specific one)
GET     ./mgmt/tm/ltm/virtual/*                                         # List specified virtual server (cannot list all)
GET     ./mgmt/tm/ltm/virtual/~<partition>~<virtual-name>               # List properties of specified virtual servers 
GET     ./mgmt/tm/ltm/virtual/~<partition>~<virtual-name>/*             # List properties (profiles, policies, ?) of specified virtual servers
GET     ./mgmt/tm/ltm/virtual/~<partition>~<virtual-name>/profiles      # List profiles of specified virtual servers
GET     ./mgmt/tm/ltm/virtual/~<partition>~<virtual-name>/policies      # List policies of specified virtual servers

POST    /mgmt/tm/ltm/virtual/*/*                                       # Add properties (profiles, policies, ?) all virtual servers
POST    /mgmt/tm/ltm/virtual/~<partition>~<virtual-name>/*             # Add properties (profiles, policies, ?) of specified virtual servers
POST    /mgmt/tm/ltm/virtual/~<partition>~<virtual-name>/profiles      # Add profiles of specified virtual servers
POST    /mgmt/tm/ltm/virtual/~<partition>~<virtual-name>/policies      # Add policies of specified virtual servers

PATCH   /mgmt/tm/ltm/virtual/*                                         # Modify properties all virtual servers
PATCH   /mgmt/tm/ltm/virtual/~<partition>~<virtual-name>               # Modify properties of specified virtual servers

DELETE  /mgmt/tm/ltm/virtual/*/*/*                                     # Delete properties (profiles, policies, ?) all virtual servers
DELETE  /mgmt/tm/ltm/virtual/~<partition>~<virtual-name>/*/*           # Delete properties (profiles, policies, ?) of specified virtual servers
DELETE  /mgmt/tm/ltm/virtual/~<partition>~<virtual-name>/profiles/*    # Delete profiles of specified virtual servers
DELETE  /mgmt/tm/ltm/virtual/~<partition>~<virtual-name>/policies/*    # Delete policies of specified virtual servers

###################
# pools

GET     /mgmt/tm/ltm/pool                                              # List all pools (cannot list a specific one)
GET     /mgmt/tm/ltm/pool/*                                            # List specified pools (cannot list all)
GET     /mgmt/tm/ltm/pool/~<partition>~<pool-name>                     # List properties of specified pools
GET     /mgmt/tm/ltm/pool/~<partition>~<pool-name>/*                   # List properties (members, ?) of specified pools
GET     /mgmt/tm/ltm/pool/~<partition>~<pool-name>/members             # List members of specified pools

POST    /mgmt/tm/ltm/pool/*/*                                          # Add properties (members, ?) all pools
POST    /mgmt/tm/ltm/pool/~<partition>~<pool-name>/*                   # Add properties in specified pool
POST    /mgmt/tm/ltm/pool/~<partition>~<pool-name>/members             # Add members of specified pools

DELETE  /mgmt/tm/ltm/pool/*/*/*                                        # Delete properties (members, ?) all pools
DELETE  /mgmt/tm/ltm/pool/~<partition>~<pool-name>/*/*                 # Delete properties in specified pool
DELETE  /mgmt/tm/ltm/pool/~<partition>~<pool-name>/members/*           # Delete members of specified pools

PATCH   /mgmt/tm/ltm/pool/*                                            # Modify properties all pools
PATCH   /mgmt/tm/ltm/pool/~<partition>~<pool-name>                     # Modify properties in specified pool

PATCH   /mgmt/tm/ltm/pool/*/*/*                                        # Modify properties (members) all pools (administrative state)
PATCH   /mgmt/tm/ltm/pool/~<partition>~<pool-name>/*/*                 # Modify properties (members, ?) in specified pool (administrative state)
PATCH   /mgmt/tm/ltm/pool/~<partition>~<pool-name>/members/*           # Modify members of specified pools (administrative state)
PATCH   /mgmt/tm/ltm/pool/~<partition>~<pool-name>/members/~<partition>~<node-name>    # Modify specified members of specified pools (administrative state)

I.e. for virtual servers you may allow a GET for /mgmt/tm/ltm/virtual. This will permit listing of all virtual servers without being able to specify a virtual server.
Allowing GET for /mgmt/tm/ltm/virtual/* will not allow listing all virtuals but the user can specify a virtual to be listed.
As well you can set permission to list specified virtuals only by allowing GET for /mgmt/tm/ltm/virtual/~<partition>~<virtual-name>.
Feel free to have a combination of tuples in a role.
This way the RBAC allows very granular access controll.
By allowing GET methods only you make sure there will be READ ONLY access only with this role. The permission of other methods as described above will provide more priviledges.
The schema can easily be extended to other LTM compents like nodes, monitors and profiles or to modules like NET.

I did all tests on bash by using cURL to retrieve a new token, put it into a shell variable and use it for the administrative request. No worries to track current tokens. It´s a one-liner as follows:

bigip=10.100.100.61; token=`curl -svk -X POST -H "Content-Type: application/json" -d '{"username":"admin","password":"admin","loginProviderName":"local"}' "https://${bigip}/mgmt/shared/authn/login" | \
grep -oE '"token":{[^}]+}' | grep -oE '"token":"[^"]+"' | awk -F : '{print $2}' | tr -d \"`; \
curl -sk -H "Content-Type: application/json" -H "X-F5-Auth-Token: $token" -X GET "https://${bigip}/mgmt/tm/ltm/virtual" | \
python -m json.tool
1
Comment made 06-Jun-2018 by aries 107

Hi everyone! Thanks to this guide, I was able to grant access to a guest user for the rest interface. In reference to g.clark's guide (step 4 - ADD USER ACCOUNT TO THE ROLE WITH PATCH METHOD), what will be the command to revoke the user's access to the rest interface?

0
Comment made 12-Jun-2018 by Stephan Manthey 3803

Hi, as far as I understand, a single permission (added via a "link" entry) cannot be removed. Instead the whole collection of links needs to be replaced. Please let us know, in case you find an alternative solution. Thanks, Stephan

0