Who is able to access iMessage on Apple's servers?
See iOS Security, pp30&ndash;32:


  iMessage
  
  Apple iMessage is a messaging service for iOS devices and Mac computers. iMessage supports text and attachments such as photos, contacts, and locations. Messages appear on all of a user’s registered devices so that a conversation can be continued from any of the user’s devices. iMessage makes extensive use of the Apple Push Notification service (APNs). Apple does not log messages or attachments, and their contents are protected by end-to-end encryption so no one but the sender and receiver can access them. Apple cannot decrypt the data.
  
  When a user turns on iMessage, the device generates two pairs of keys for use with the service: an RSA 1280-bit key for encryption and an ECDSA 256-bit key for signing. For each key pair, the private keys are saved in the device’s keychain and the public keys are sent to Apple’s directory service (IDS), where they are associated with the user’s phone number or email address, along with the device’s APNs address.
  
  As users enable additional devices for use with iMessage, their public keys, APNs addresses, and associated phone numbers are added to the directory service. Users can also add more email addresses, which will be verified by sending a confirmation link. Phone numbers are verified by the carrier network and SIM. Further, all of the user’s registered devices display an alert message when a new device, phone number, or email address is added.
  
  How iMessage sends and receives messages
  
  Users start a new iMessage conversation by entering an address or name. If they enter a phone number or email address, the device contacts the IDS to retrieve the public keys and APNs addresses for all of the devices associated with the addressee. If the user enters a name, the device first utilizes the user’s Contacts app to gather the phone numbers and email addresses associated with that name, then gets the public keys and APNs addresses from the IDS.
  
  The user’s outgoing message is individually encrypted using AES-128 in CTR mode for each of the recipient’s devices, signed using the sender’s private key, and then dispatched to the APNs for delivery. Metadata, such as the timestamp and APNs routing information, is not encrypted. Communication with APNs is encrypted using TLS.
  
  If the message text is too long, or if an attachment such as a photo is included, the attachment is encrypted using a random key and uploaded to iCloud. The key and URI (Uniform Resource Identifier) for the attachment are encrypted and signed, as shown below.
  
  
  
  For group conversations, this process is repeated for each recipient and their devices.
  
  On the receiving side, each device receives its copy of the message from APNs, and, if
  necessary, retrieves the attachment from iCloud. The incoming phone number or email
  address of the sender is matched to the receiver’s contacts so that a name can be
  displayed, if possible.
  
  As with all push notifications, the message is deleted from APNs when it is delivered.
  Unlike other APNs notifications, however, iMessage messages are queued for delivery
  to offline devices. Messages are stored for up to seven days.


If implemented properly, this means that your messages on Apple's servers can only be decrypted by devices that you registered with Apple for iMessage before they were sent.  Furthermore, you must connect the device to Apple's push service within 7 days of message transmission or else the messages will be purged.

However, that is a big "if":


There is no independent audit of Apple's codebase, so the devices that you and your correspondents use might contain "backdoors" (deliberate or otherwise) e.g. weaknesses in key generation or information leakage through covert channels&mdash;and that's assuming the devices themselves are "secure";
There is no way that your correspondents can verify that the discovered public keys (received from Apple's directory) are actually paired with the private keys you hold on your devices&mdash;Apple could substitute them for those of a "man in the middle" or simply add an additional public key for a device that you do not own but which will then be able to decrypt all messages destined for you (you can attempt to detect such attacks by querying for your public keys from another account and verifying the response, although there is still no guarantee that Apple aren't providing a different response to other parties);
As always, security is only as good as the weakest link: your correspondents have full, unencrypted access to your conversations and any compromise of them or their devices would lead to a total compromise of your communication.