Transcription
IBM CloudWhite paperOriginal: 04/19/17Updated: 04/19/17IBM UrbanCode Deploysecurity featuresSummaryThis document describes the IBM UrbanCode Deploysecurity features. It highlights core elements and examinesthe available options. The paper also discusses typical architectural topologies and communication protocols.Highlights Server-agent security options described,including end-to-end JMS encryption Description of keystores, trust stores, andsupported TLS protocols and ciphers Overview of team- and role-based securitymodel, including LDAP realmsLinks to related information in the Knowledge Center areprovided throughout the paper.ContentsArchitecture overview.2Server security.4AuthorTom HudsonServer-agent communication. 6Agents. 9Agent relays. 11REST API.13UrbanCode Mobile security.14User security model.15Appendices.16Index.18 Copyright International Business Machines Corporation 2017.US Government Users Restricted Rights - Use, duplication or disclosure restricted byGSA ADP Schedule Contract with IBM Corp.
IBM CloudWhite paper04/19/17Architecture overviewIBM UrbanCode Deploy uses a client-servermodel with a network of agents and relays thatcommunicate with target systems. The server provides the web-based front-end and core services,such as workflow, agent management, and security.Services can be consumed by clients and agentsor other services. Deployments are orchestratedby the server and performed by agents distributedthroughout the network. Clients access the serverthrough web browsers, the REST API, or thecommand-line client.Many services use representational state transfer(REST). REST services are web services that transfer resources over HTTPS. Resources are transferred by a self-describing format such as XMLor JSON (JavaScript Object Notation). The XMLand JSON representations typically model resourcestates at the time of agent and client requests.REST-style services achieve statelessness by ensuring that requests include all the data needed by theserver to make a coherent response.Server-agent communication is done with JavaMessage Service (JMS) and HTTPS protocols.JMS is used for basic commands and informationthat is exchanged between the server and an agent.HTTPS is used for file transfers between the serverand agents, such as uploading or downloading component version artifacts.The data tier’s relational database stores configuration and run-time data. In general, you configuresecurity for the database on the database server,not in IBM UrbanCode Deploy. IBM UrbanCodeDeploy communicates with the database by usingthe Java Database Connectivity (JDBC). The datatier’s file store, CodeStation, contains versionedartifacts. Reporting tools can connect directly to therelational database.Figure 1. Core topologyTopologiesIBM UrbanCode Deploy typically includesa server and one ormore agents. You canconfigure multipletopologies, including ones that use highavailability and disaster recovery.Core topologyThe core installation ofIBM UrbanCode Deploy includes a server,agents, database, and2
IBM CloudWhite paper04/19/17a license server. Agents can be installed on cloudenvironments, virtual machines (VMs), containers,or physical systems. Most organizations configurethe data tier with network storage and a clustereddatabase.Agents in the same network as the server continueto communicate directly to the server.High-availability clustered topologiesHigh-availability topologies use multiple servers.These servers can all be running at the same time toshare the load (as in a clustered topology), or theycan be waiting for another server to fail (as in acold standby topology).Figure 1 illustrates the core topology.Figure 2. Multi-region topologyTypically, customers who employ a clustered topology use a load balancer to distribute work. UsersMulti-region topologyconnect directly to the load balancer, which sendsthem to an active server. When using HTTP orHTTPS, agents connect to the load balancer. Whenusing JMS, agents connect to servers or relaysthrough a JMS mesh. The servers store their fileson a shared database and file system.If your environment has multiple security zonesthat are divided by firewalls, you can use agentrelays to connect agents to the server through thefirewalls. You can install an agent relay outside thefirewall to allow agents on those environments toconnect to the server through the firewall, as shownin Figure 2.Remote agents open connections to the agent relay.3
IBM CloudWhite paper04/19/17Server securityDisaster recovery topologiesOne way to prepare for disaster recovery is tohave a cold standby system, including a stoppedserver and a replicated copy of the database and filesystem. When the primary system fails, the coldstandby is brought online and promoted to primaryserver. Once online, the standby reestablishes connections with all agents, performs recovery, andproceeds with any queued processes.IBM UrbanCode Deploy uses several technologiesto provide security. Some features cannot be disabled, such as Transport Layer Security (TLS) forJMS communication. Other features can be configured to meet your requirements. Some features areenabled by default, such as end-to-end JMS encryption, while others are disabled by default, such asmutual authentication.Blueprint design topologyTLS technologyTo work with blueprints on clouds using OpenStackHeat, including OpenStack-based clouds, AmazonWeb Services, SoftLayer, VMware vCenter, andMicrosoft Azure, you use a topology that includesthe blueprint design server and engine.TLS is a standard technology that secures clientserver communication by encrypting communication. Data are encrypted before being sent anddecrypted by the recipient. Communications cannotbe deciphered or modified by third-parties.TLS technology uses digital certificates to securecommunications. A digital certificate is a cryptographically signed document that combines a cryptographic key with an organization’s fully qualifieddomain name (FQDN).Digital certificates use public key cryptographywhich works by using two keys to encrypt anddecrypt messages. The public key is stored in thecertificate and is available publicly. Messages thatare encrypted with the public key can only be decrypted with the private key.Digital certificates and private keys are stored separately in the server’s key store. Agents and agentrelays also maintain their own key stores. See “Keystores and trust stores” on page 16.How TLS worksWhen the server receives a communication request from a user or agent, the server presents itscertificate to the requestor. If the requestor truststhe certificate, it uses the certificate’s public key toencrypt session messages. The server then uses its4
IBM CloudWhite paper04/19/17private key to decrypt messages encrypted with itspublic key.certificate in its trust store. See, “Key stores andtrust stores” on page 16.IBM UrbanCode Deploy automatically uses TLSsecurity for JMS-based communications. TLStechnology is automatically activated when youinstall an agent relay or before you connect to therelay. TLS technology cannot be turned off for JMScommunication.You can enable mutual authentication for JMScommunications for additional security. See, “TLSmutual authentication” on page 5.Other featuresIn addition to TLS technology, IBM UrbanCodeDeploy provides an additional option for JMSbased communications. End-to-end JMS encryptionensures that agents cannot send messages to oneanother after they are connected to the JMS mesh.In addition, messages cannot be read or modifiedby other agents, relays, or anything else connectedto the JMS mesh. See, “End-to-end JMS encryption” on page 7.During installation, you also have the option to useTLS technology for HTTPS communications. Mostusers implement this option unless they install IBMUrbanCode Deploy for a trial or demo. If you donot implement TLS technology for HTTPS duringinstallation, you can implement it later.You can also configure agents to verify the server’sidentity for HTTPS communication. This optionprevents agents from connecting to the server overHTTPS unless the certificate’s Common Name(CN) matches the host name of the server. See,“Agent verification of server certificate for HTTPScommunication” on page 8.Role-based access controls are available that determine the actions that users can perform. See “Usersecurity model” on page 15.TokensTokens are randomly generated passwords. Tokensprovide authentication for agents, agent relays, users, and external systems. Agents use tokens whenthey run process steps and communicate with theserver and external services. Users can use tokens with the command-line interface (CLI) clientinstead of supplying a user name and password incertain situationsTLS mutual authenticationWith mutual authentication, messages are stillencrypted but clients are also required to authenticate themselves by providing digital certificates tothe server. In mutual authentication mode, servers, local agents, and agent relays provide digitalcertificates to one another. IBM UrbanCode Deploycertificates can be self-signed or be from a trustedcertificate authority (CA).Tokens have the same permissions as the usersfor whom they are created. User accounts canbe designed for a particular token. For example,you might create tokens for agent relays with the‘agentRelay’ user.In mutual authentication mode, the server storesthe certificate from each agent in its trust storeand each agent stores the server’s certificate in itstrust store. If you use agent relays, certificates areswapped between agents, agent relays, and theserver. If you use a certificate authority, the certificate exchanges are unnecessary. Messages arerejected if the recipient cannot find the sender’sTokens with administrator permissions are used insome situations: 5Some integrations require tokens with administratorpermissions. For example, when integrating with IBMUrbanCode Release, the token provided to IBM
IBM CloudWhite paper04/19/17 UrbanCode Release must be created by a user withadministrator permissions.Server-agent communicationWhen a user logs onto the CLI client by using theadmin user account, a token is generated that expiresafter 24 hours and is then deleted.The IBM UrbanCode Deploy server sends commands and files to the agents or agent relays distributed around the network. Agents exchange statusinformation with the server. Depending on the typeof data exchanged, communication is done by usingthe HTTPS or JMS protocols.When processes run on agents as the admin.CodeStationThe server uses the JMS channel to send agentcommands. The agent worker process uses JMSfor all server communications. Agent processes aredescribed later, see “Agents” on page 9.IBM UrbanCode Deploy provides an artifactrepository, CodeStation. Artifacts represent deployable items such as files, images, database schemas,configuration materials, or anything else associatedwith a software project.The server listens on web sockets for agents, agentrelays, and clients. By default, the server listenson only three ports: port 7918 for JMS, 8080 forHTTP, and 8443 for HTTPS. Agent relays listen onthree ports for agent communication. The defaultports used by agent relays are JMS 7916, HTTPproxy 20080, and Codestation uses the HTTP proxyport 1.CodeStation tracks component versions and maintains a complete history for all components. Without the repository, artifacts would have to be pulledfrom network shares or some other system, increasing both security risks and the potential for error.Files are transferred using HTTPS. At deploymenttime, existing files in the target location can bevalidated against a SHA256 hash, and replaced ifmodified.To monitor the health of the agent worker process,the agent monitor process listens for communication from the agent worker process on a port boundto localhost. Agent worker processes do not listenon ports. The worker process uses JMS for systemcommunications, and HTTP REST services whenperforming plug-in steps or retrieving informationfrom the server. Credentials are provided by theJMS message that initiates execution of a plug-instep.Because JMS connections are persistent, IBM UrbanCode Deploy does not have to continually openand close ports, which enables the server to communicate with agents at any time while remainingsecure and scalable.Persistent server-agent communication providessignificant benefits to performance, security, availability, and disaster recovery.6
IBM CloudWhite paper04/19/17Mutual authenticationReference: http://www.ibm.com/support/knowledgecenter/SS4GSP 6.2.1/com.ibm.udeploy.doc/topics/c securityover.htmlWhen mutual authentication mode is active, UrbanCode Deploy uses it for JMS-based server-agentcommunication. In this mode, the server providesa digital certificate to each agent and agent relay,and each agent and agent relay provides one tothe server. Certificate checks are performed by theJVM according to its own algorithm. Certificatescan be issued from a certification authority (CA)if desired, in which instance certificates do nothave to be swapped. The integrity of the contentis established by the mechanisms built into TLStechnology. This mode can be implemented duringinstallation or activated afterward.JMS communicationsServer-agent JMS communication is subscriptionbased. The server consumes agent messages froma queue. By default, the server uses port number7918 for JMS communication. The certificate forTLS communication on the JMS port is stored inthe server.keystore file. If mutual authentication isdisabled, the file is used only to encrypt networktraffic. See, “Key stores used for JMS communication” on page 16.End-to-end JMS encryptionUnless you use a certification authority, the serverstores the certificate from each agent in its truststore, and each agent stores the server’s certificatein its trust store. If you use agent relays, certificatesare swapped between agents, agent relays, and theserver. Connections are rejected if the recipientcannot find the sender’s certificate in its trust store.See “Key stores and trust stores” on page 16.End-to-end JMS encryption ensures that agentscannot send messages to one another after they areconnected to the JMS mesh. It also ensures thatJMS clients cannot read messages that are not sentto them. With end-to-end encryption enabled, youdo not need mutual authentication. End-to-endencryption requires considerably less configuration than mutual authentication, while ensuring thatagents do not accept messages from rogue serversor other malicious entities.Digital certificates are exchanged by using the keytool utility that is provided with the Java developerkit. You export a participant’s certificate and thenimport it into another participant’s trust store.With the end-to-end JMS encryption feature, theserver generates an encryption key the first timeagents connect to the server. The agent stores thekey in its agent installation/conf/agent/agent-key.properties file.When you use mutual authentication mode, youmust turn it on for the server, agents, and agent relays; otherwise, they cannot connect to one another.Mutual authentication mode is not used for HTTPScommunication.Using the IBM UrbanCode Deploy web-baseddashboard, you can view agent API keys. If anagent is compromised, you can revoke the API keyand prevent the agent from connecting to the server.Mutual authentication can be implemented forhigh-availability environments by swapping allagent and agent relay certificates with each server.All agents and agent relays have certificates fromall servers, and all servers have certificates fromall agents and agent relays. Once again, if you usea certification authority, you do not need to swapcertificates. Each server uses the same certificate.For this purpose, load balancers are ignored.Reference: http://www.ibm.com/support/knowledgecenter/SS4GSP 6.2.1/com.ibm.udeploy.install.doc/topics/ssl addl security 2.html7
IBM CloudWhite paper04/19/17HTTP/HTTPS server-agent communicationReference: http://www.ibm.com/support/knowledgecenter/SS4GSP 6.2.1/com.ibm.udeploy.install.doc/topics/ssl addl security.htmlWhile most server-agent communication is donewith JMS, some agent activities, such as postinglogs, and moving files to CodeStation, use HTTPS.In high-availability topologies, HTTP(S) serveragent communication is handled by the load balancer and any server can perform validation for anyrequest.Securing user-created propertiesSecure properties are not displayed in the userinterface but are instead redacted in the form of“*****”. Agents are passed property values but notnames. Secure properties, such as passwords, areencrypted with an Advanced Encryption Standard(AES) algorithm and a 128-bit key.By default, incoming HTTP connections to theserver’s web interface uses port 8080. For incoming HTTPS connections, use port 8443.An outline of how secure properties are handled isprovided in the following steps:Agent verification of server certificate forHTTPS communication1. The server loads all the secure properties and decryptsthem as necessary for input properties.You can configure agents to verify the identity ofthe server for communication that uses the HTTPSprotocol. When enabled, this option prevents agentsfrom connecting to the server over HTTPS unlessthe certificate’s CN matches the host name to whichthe agent is connecting. You can implement thisfeature with self-signed certificates or certificatesissued by a certification authority.2. The server uses JMS to send a list of all inputproperties and secure values to the agent over TLS.3. If the plug-in supports an encrypted property format, anencrypted temporary file is written to the file system.The secret for the encryption is generated on a per stepbasis and passed to the plug-in step through stdin. If theplug-in does not support an encrypted property format,a plain text file is written.When you install UrbanCode Deploy, a private keyand self-signed certificate with the alias serverare stored in the server’s tomcat.keystorefile. This certificate is presented to agents, agentrelays, and users that connect to the server usingHTTPS. When you enable agent verification ofserver certificates, the key is modified so that theagent can verify the host name of the server. Agentsare then configured to accept the trusted certificateand to also verify the host name of the server.4. The agent starts the plug-in step.5. If the plug-in supports an encrypted property format,the temporary file is read and decrypted with the secretread from stdin. Otherwise, the plain text file is read.6. Before the logs are uploaded to the server, the servervalues found in the file are obfuscated.7. The logs and output properties are uploaded once thestep is complete. If the plug-in supports an encryptedproperty format, stored properties are encryptedThis option requires that the location of the Javadeveloper kit (JDK) keytool utility is in the systempath.8. The logs, output properties, and input properties filesare removed from the agent.Agent relays can be configured to verify the identity of the server. If you do not enable this option,then only agents need to validate server certificates.See “Agent relay artifact caching” on page
ogy use a load balancer to distribute work. Users connect directly to the load balancer, which sends them to an active server. When using HTTP or HTTPS, agents connect to the load balancer. When using JMS, agents connect to servers or relays through a JMS mesh. The server
