Skip to main content
undefined
undefined

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

undefined

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Release notes

October 30, 2018

Here’s the latest on how we’ve been trying to make cloud.gov simpler and more secure. (If you find yourself needing to
explain cloud.gov to coworkers or leadership, take a look at our new two-pager!)

New dashboard (now in preview mode)

Check out the preview version of our new web dashboard. It still gives you
web-based access to an overview of your applications and lets you do common tasks, but this new version brings many more
command-line tasks to the web like viewing application logs and the ability to SSH into your application. It’s still a
preview because there are some confusing parts of the interface, and it’s missing a few tools from the current dashboard
(such as inviting a new user at the same time as giving them a role in your org or space).

For now, both dashboards are live; we’ll be retiring the original about a month from now. If you’ve got thoughts to
share, let us know. We especially want you to tell us if you rely on something in the current dashboard that
you can’t find in the new dashboard!

Updated password rotation policy

Following the revised NIST Digital Identity Guidelines and the
corresponding FedRAMP Digital Identity
Requirements, we’ve improved
our password security policies.

  • If you log into cloud.gov using a cloud.gov user account (not using agency single sign-on at EPA, FDIC, GSA, or NSF),
    it no longer requires you to change your password every 90 days.

  • If you use service accounts for automating application deployment or
    event-auditing, those automatically-generated credentials no longer expire after 90 days.

To meet NIST and FedRAMP requirements, we’ve also added new security controls when you create or change a cloud.gov
account password. cloud.gov prevents you from creating easily-compromised passwords by automatically checking against
common weak passwords.

Internal routing

In the past, every application route (address) that you created for a cloud.gov application was automatically an address
accessible over the internet, so if you wanted to have a route for an internal application, you needed to put in careful
attention to what was accessible over that route (including thinking about authentication and authorization for that
application).

Now, you can use apps.internal as a route for anything that shouldn’t be public (or shouldn’t be public yet).
That’ll make your app internal automatically. You use an allow list to decide which other applications should be able to
talk to your internal application. For more details, see Internal Routes in the Cloud Foundry
documentation and this Cloud
Foundry blog post.

Polyglot service discovery

Along with internal routing, cloud.gov now also offers polyglot service discovery. You can use DNS from within your
applications to refer to instances of that application. That means you can have different instances of the app act as
leader and follower nodes rather than just scaling naively, which enables clustered applications.

You can also use these routes across language stacks — because it’s DNS-based, it’s not tied to a particular language
library. See this Cloud Foundry blog
post for details.

Coming soon

VPN backhaul to other networks

If you have applications on cloud.gov and you want them to be able to interact with other applications over a VPN
connection — in your data center, in an IaaS, with your hosting provider, anywhere — we’re working on making this
available to you. We’re able to dedicate a specific area for these types of applications,
along with a VPN backhaul that enables direct connections to the applications you have on other networks.

Having this in place will make it easier to migrate applications from legacy infrastructure to the cloud. If your
services are nested together and you can’t move everything at once, you’ll be able to migrate one application at a time
without interrupting service or exposing information to the open internet.

We’re working through FedRAMP testing and approval for this feature so it isn’t available yet, but if you’re interested
in learning more and setting this up in the future, send us an email. We can set up a call
with you and your agency network security team to preview how it will work, so that your agency can get on board when
this is ready.

Updates and upgrades

  • logs.fr.cloud.gov has been upgraded to Elasticsearch/Kibana
    6.x     - Our network architecture has been improved,
    and our outgoing internet traffic capacity has increased 75x - We have a new S3 plan for
    sandboxes     that automatically clears your S3 contents whenever your sandbox is
    cleared - We offer a custom domain service that doesn’t use CloudFront,
    since CloudFront is currently outside the AWS FedRAMP P-ATO boundary

Thanks for using cloud.gov. If there’s more we can do to make your work easier, let us know.