Kategorie: Kubernetes

Using RBAC, Generally Available in Kubernetes v1.8

Editor’s note: this post is part of a series of in-depth articles on what’s new in Kubernetes 1.8. Today’s post comes from Eric Chiang, software engineer, CoreOS, and SIG-Auth co-lead.Kubernetes 1.8 represents a significant milestone for the role-based access control (RBAC) authorizer, which was promoted to GA in this release. RBAC is a mechanism for controlling access to the Kubernetes API, and since its beta in 1.6, many Kubernetes clusters and provisioning strategies have enabled it by default.Going forward, we expect to see RBAC become a fundamental building block for securing Kubernetes clusters. This post explores using RBAC to manage user and application access to the Kubernetes API.Granting access to usersRBAC is configured using standard Kubernetes resources. Users can be bound to a set of roles (ClusterRoles and Roles) through bindings (ClusterRoleBindings and RoleBindings). Users start with no permissions and must explicitly be granted access by an administrator.All Kubernetes clusters install a default set of ClusterRoles, representing common buckets users can be placed in. The “edit” role lets users perform basic actions like deploying pods; “view” lets a user observe non-sensitive resources; “admin” allows a user to administer a namespace; and “cluster-admin” grants access to administer a cluster.$ kubectl get clusterroles NAME            AGEadmin           40mcluster-admin   40medit            40m# …view            40mClusterRoleBindings grant a user, group, or service account a ClusterRole’s power across the entire cluster. Using kubectl, we can let a sample user “jane” perform basic actions in all namespaces by binding her to the “edit” ClusterRole:$ kubectl create clusterrolebinding jane –clusterrole=edit –user=jane$ kubectl get namespaces –as=janeNAME          STATUS    AGEdefault       Active    43mkube-public   Active    43mkube-system   Active    43m$ kubectl auth can-i create deployments –namespace=dev –as=janeyesRoleBindings grant a ClusterRole’s power within a namespace, allowing administrators to manage a central list of ClusterRoles that are reused throughout the cluster. For example, as new resources are added to Kubernetes, the default ClusterRoles are updated to automatically grant the correct permissions to RoleBinding subjects within their namespace.Next we’ll let the group “infra” modify resources in the “dev” namespace:$ kubectl create rolebinding infra –clusterrole=edit –group=infra –namespace=devrolebinding “infra” createdBecause we used a RoleBinding, these powers only apply within the RoleBinding’s namespace. In our case, a user in the “infra” group can view resources in the “dev” namespace but not in “prod”:$ kubectl get deployments –as=dave –as-group=infra –namespace devNo resources found.$ kubectl get deployments –as=dave –as-group=infra –namespace prodError from server (Forbidden): deployments.extensions is forbidden: User “dave” cannot list deployments.extensions in the namespace “prod”.Creating custom rolesWhen the default ClusterRoles aren’t enough, it’s possible to create new roles that define a custom set of permissions. Since ClusterRoles are just regular API resources, they can be expressed as YAML or JSON manifests and applied using kubectl.Each ClusterRole holds a list of permissions specifying “rules.” Rules are purely additive and allow specific HTTP verb to be performed on a set of resource. For example, the following ClusterRole holds the permissions to perform any action on “deployments”, “configmaps,” or “secrets”, and to view any “pod”:kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:  name: deployerrules:- apiGroups: [“apps”]  resources: [“deployments”]  verbs: [“get”, “list”, “watch”, “create”, “delete”, “update”, “patch”]- apiGroups: [“”] # “” indicates the core API group  resources: [“configmaps”, “secrets”]  verbs: [“get”, “list”, “watch”, “create”, “delete”, “update”, “patch”]- apiGroups: [“”] # “” indicates the core API group  resources: [“pods”]  verbs: [“get”, “list”, “watch”]Verbs correspond to the HTTP verb of the request, while the resource and API groups refer to the the resource being referenced. Consider the following Ingress resource:apiVersion: extensions/v1beta1kind: Ingressmetadata:  name: test-ingressspec:  backend:    serviceName: testsvc    servicePort: 80To POST the resource, the user would need the following permissions:rules:- apiGroups: [“extensions”] # “apiVersion” without version  resources: [“ingresses”]  # Plural of “kind”  verbs: [“create”]         # “POST” maps to “create”Roles for applicationsWhen deploying containers that require access to the Kubernetes API, it’s good practice to ship an RBAC Role with your application manifests. Besides ensuring your app works on RBAC enabled clusters, this helps users audit what actions your app will perform on the cluster and consider their security implications.A namespaced Role is usually more appropriate for an application, since apps are traditionally run inside a single namespace and the namespace’s resources should be tied to the lifecycle of the app. However, Roles cannot grant access to non-namespaced resources (such as nodes) or across namespaces, so some apps may still require ClusterRoles.The following Role allows a Prometheus instance to monitor and discover services, endpoints, and pods in the “dev” namespace:kind: Rolemetadata:  name: prometheus-role  namespace: devrules:- apiGroups: [“”] # “” refers to the core API group  Resources: [“services”, “endpoints”, “pods”]  verbs: [“get”, “list”, “watch”]Containers running in a Kubernetes cluster receive service account credentials to talk to the Kubernetes API, and service accounts can be targeted by a RoleBinding. Pods normally run with the “default” service account, but it’s good practice to run each app with a unique service account so RoleBindings don’t unintentionally grant permissions to other apps.To run a pod with a custom service account, create a ServiceAccount resource in the same namespace and specify the `serviceAccountName` field of the manifest.apiVersion: apps/v1beta2 # Abbreviated, not a full manifestkind: Deploymentmetadata:  name: prometheus-deployment  namespace: devspec:  replicas: 1  template:    spec:      containers:      – name: prometheus        image: prom/prometheus:v1.8.0        command: [“prometheus”, “-config.file=/etc/prom/config.yml”]    # Run this pod using the “prometheus-sa” service account.    serviceAccountName: prometheus-sa—apiVersion: v1kind: ServiceAccountmetadata:  name: prometheus-sa  namespace: devGet involvedDevelopment of RBAC is a community effort organized through the Auth Special Interest Group, one of the many SIGs responsible for maintaining Kubernetes. A great way to get involved in the Kubernetes community is to join a SIG that aligns with your interests, provide feedback, and help with the roadmap.About the authorEric Chiang is a software engineer and technical lead of Kubernetes development at CoreOS, the creator of Tectonic, the enterprise-ready Kubernetes platform. Eric co-leads Kubernetes SIG Auth and maintains several open source projects and libraries on behalf of CoreOS.
Quelle: kubernetes

It Takes a Village to Raise a Kubernetes

Editor’s note: this post is part of a series of in-depth articles on what’s new in Kubernetes 1.8, written by Jaice Singer DuMars from Microsoft.Each time we release a new version of Kubernetes, it’s enthralling to see how the community responds to all of the hard work that went into it. Blogs on new or enhanced capabilities crop up all over the web like wildflowers in the spring. Talks, videos, webinars, and demos are not far behind. As soon as the community seems to take this all in, we turn around and add more to the mix. It’s a thrilling time to be a part of this project, and even more so, the movement. It’s not just software anymore.When circumstances opened the door for me to lead the 1.8 release, I signed on despite a minor case of the butterflies. In a private conversation with another community member, they assured me that “being organized, following up, and knowing when to ask for help” were the keys to being a successful lead. That’s when I knew I could do it — and so I did.From that point forward, I was wrapped in a patchwork quilt of community that magically appeared at just the right moments. The community’s commitment and earnest passion for quality, consistency, and accountability formed a bedrock from which the release itself was chiseled.The 1.8 release team proved incredibly cohesive despite a late start. We approached even the most difficult situations with humor, diligence, and sincere curiosity. My experience leading large teams served me well, and underscored another difference about this release: it was more valuable for me to focus on leadership than diving into the technical weeds to solve every problem.Also, the uplifting power of emoji in Slack cannot be overestimated.An important inflection point is underway in the Kubernetes project. If you’ve taken a ride on a “startup rollercoaster,” this is a familiar story. You come up with an idea so crazy that it might work. You build it, get traction, and slowly clickity-clack up that first big hill. The view from the top is dizzying, as you’ve poured countless hours of life into something completely unknown. Once you go over the top of that hill, everything changes. Breakneck acceleration defines or destroys what has been built.In my experience, that zero gravity point is where everyone in the company (or in this case, project) has to get serious about not only building something, but also maintaining it. Without a commitment to maintenance, things go awry really quickly. From codebases that resemble the Winchester Mystery House to epidemics of crashing production implementations, a fiery descent into chaos can happen quickly despite the outward appearance of success. Thankfully, the Kubernetes community seems to be riding our growth rollercoaster with increasing success at each release.As software startups mature, there is a natural evolution reflected in the increasing distribution of labor. Explosive adoption means that full-time security, operations, quality, documentation, and project management staff become necessary to deliver stability, reliability, and extensibility. Also, you know things are getting serious when intentional architecture becomes necessary to ensure consistency over time.Kubernetes has followed a similar path. In the absence of company departments or skill-specific teams, Special Interest Groups (SIGs) have organically formed around core project needs like storage, networking, API machinery, applications, and the operational lifecycle. As SIGs have proliferated, the Kubernetes governance model has crystallized around them, providing a framework for code ownership and shared responsibility. SIGs also help ensure the community is sustainable because success is often more about people than code.At the Kubernetes leadership summit in June, a proposed SIG architecture was ratified with a unanimous vote, underscoring a stability theme that seemed to permeate every conversation in one way or another. The days of filling in major functionality gaps appear to be over, and a new era of feature depth has emerged in its place.Another change is the move away from project-level release “feature themes” to SIG-level initiatives delivered in increments over the course of several releases. That’s an important shift: SIGs have a mission, and everything they deliver should ultimately serve that. As a community, we need to provide facilitation and support so SIGs are empowered to do their best work with minimal overhead and maximum transparency.Wisely, the community also spotted the opportunity to provide safe mechanisms for innovation that are increasingly less dependent on the code in kubernetes/kubernetes. This in turn creates a flourishing habitat for experimentation without hampering overall velocity. The project can also address technical debt created during the initial ride up the rollercoaster. However, new mechanisms for innovation present an architectural challenge in defining what is and is not Kubernetes. SIG Architecture addresses the challenge of defining Kubernetes’ boundaries. It’s a work in progress that trends toward continuous improvement.This can be a little overwhelming at the individual level. In reality, it’s not that much different from any other successful startup, save for the fact that authority does not come from a traditional org chart. It comes from SIGs, community technical leaders, the newly-formed steering committee, and ultimately you.The Kubernetes release process provides a special opportunity to see everything that makes this project tick. I’ll tell you what I saw: people, working together, to do the best they can, in service to everyone who sets out on the cloud native journey.
Quelle: kubernetes

Finnish Railways and Accenture Partner to Modernize Key Transportation Apps  

VR Group is the state-owned company that runs Finnish Railways, and provides 82 million passenger train rides and transports 36 million tons of goods per year. The 150+ year old transportation business is broken into separate divisions, each with their own technology departments. Finnish Railways does not have an in-house development team, so each division leverages external vendors and partners for their application development needs.
On Day 2 of DockerCon Europe, Markus Niskanen, Integration Manager at VR Group, and Oscar Renalias, Solutions Architect at Accenture presented their story on how they worked together to modernize critical business applications for Finnish Railways, including the reservation and commuter applications.

Partnership Drives Faster Results
Finnish Railways began working with Accenture, a long-time partner, to design a new common application platform based on Docker Enterprise Edition (EE). Leveraging Accenture’s Container Migration Factory, Finnish Railways had access to hundreds of Docker-trained Accenture architects which meant that this project could be delivered more efficiently. For example, Accenture has customized Terraform scripts that set up a Docker EE environment in AWS in about 25 minutes.
They started with the old reservation system which was running on mainframe and a legacy commuter service application. They rewrote these applications with microservices and also moved from proprietary software platforms to include more open source components.
Expanding App Modernization Across the Organization
The implementation of Docker EE began about a year ago and as the first applications were getting rewritten, the team also saw the opportunity to simply migrate some existing applications to the Docker platform. Docker EE has now become the single platform for all types of applications – from non-production development workloads to greenfield microservices apps to brownfield legacy applications.
The commuter services app went live in June, and the new reservation system went live in August of this year. Finnish Railways has already seen some impressive results:

Average cost savings of 50%
Better visibility into all of the apps with centralized logging and monitoring
Standardization on a common platform and architecture that can be leveraged across all applications and by all of Finnish Railways’ vendors
A consistent app delivery pipeline that works the same for everyone. This makes it easy to bring new contractors and vendors into the same environment and processes.

Finnish Railways has accomplished a lot this year with their Docker EE platform. These early successes have made it possible for Markus to now bring the platform to even more teams within the company and they are actively expanding their footprint with the goal of getting everything over to Docker EE.
To learn more about Finnish Railway’s Docker EE deployment and the services provided by Accenture, also watch their breakout session:

To learn more about Docker Enterprise Edition:

Learn more about Docker EE
Try Docker EE for free and view subscription plans 
Sign up for upcoming webinars

Finnish Railways @VRpalvelu and @Accenture Partner to Modernize Key Transportation Apps w/ #docker…Click To Tweet

The post Finnish Railways and Accenture Partner to Modernize Key Transportation Apps   appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

kubeadm v1.8 Released: Introducing Easy Upgrades for Kubernetes Clusters

Editor’s note: this post is part of a series of in-depth articles on what’s new in Kubernetes 1.8Since its debut in September 2016, the Cluster Lifecycle Special Interest Group (SIG) has established kubeadm as the easiest Kubernetes bootstrap method. Now, we’re releasing kubeadm v1.8.0 in tandem with the release of Kubernetes v1.8.0. In this blog post, I’ll walk you through the changes we’ve made to kubeadm since the last update, the scope of kubeadm, and how you can contribute to this effort.Security first: kubeadm v1.6 & v1.7Previously, we discussed planned updates for kubeadm v1.6. Our primary focus for v1.6 was security. We started enforcing role based access control (RBAC) as it graduated to beta, gave unique identities and locked-down privileges for different system components in the cluster, disabled the insecure `localhost:8080` API server port, started authorizing all API calls to the kubelets, and improved the token discovery method used formerly in v1.5. Token discovery (aka Bootstrap Tokens) graduated to beta in v1.8.In number of features, kubeadm v1.7.0 was a much smaller release compared to v1.6.0 and v1.8.0. The main additions were enforcing the Node Authorizer, which significantly reduces the attack surface for a Kubernetes cluster, and initial, limited upgrading support from v1.6 clusters.Easier upgrades, extensibility, and stabilization in v1.8We had eight weeks between Kubernetes v1.7.0 and our stabilization period (code freeze) to implement new features and to stabilize the upcoming v1.8.0 release. Our goal for kubeadm v1.8.0 was to make it more extensible. We wanted to add a lot of new features and improvements in this cycle, and we succeeded.Upgrades along with better introspectability. The most important update in kubeadm v1.8.0 (and my favorite new feature) is one-command upgrades of the control plane. While v1.7.0 had the ability to upgrade clusters, the user experience was far from optimal, and the process was risky.Now, you can easily check to see if your system can handle an upgrade by entering:$ kubeadm upgrade planThis gives you information about which versions you can upgrade to, as well as the health of your cluster.You can examine the effects an upgrade will have on your system by specifying the –dry-run flag. In previous versions of kubeadm, upgrades were essentially blind in that you could only make assumptions about how an upgrade would impact your cluster. With the new dry run feature, there is no more mystery. You can see exactly what applying an upgrade would do before applying it.After checking to see how an upgrade will affect your cluster, you can apply the upgrade by typing:$ kubeadm upgrade apply v1.8.0This is a much cleaner and safer way of performing an upgrade than the previous version. As with any type of upgrade or downgrade, it’s a good idea to backup your cluster first using your preferred solution.Self-hostingSelf-hosting in this context refers to a specific way of setting up the control plane. The self-hosting concept was initially developed by CoreOS in their bootkube project. The long-term goal is to move this functionality (currently in an alpha stage) to the generic kubeadm toolbox. Self-hosting means that the control plane components, the API Server, Controller Manager and Scheduler are workloads themselves in the cluster they run. This means the control plane components can be managed using Kubernetes primitives, which has numerous advantages. For instance, leader-elected components like the scheduler and controller-manager will automatically be run on all masters when HA is implemented if they are run in a DaemonSet. Rolling upgrades in Kubernetes can be used for upgrades of the control plane components, and next to no extra code has to be written for that to work; it’s one of Kubernetes’ built-in primitives!Self-hosting won’t be the default until v1.9.0, but users can easily test the feature in experimental clusters. If you test this feature, we’d love your feedback!You can test out self-hosting by enabling its feature gate:$ kubeadm init –feature-gates=SelfHosting=trueExtensibilityWe’ve added some new extensibility features. You can delegate some tasks, like generating certificates or writing control plane arguments to kubeadm, but still drive the control plane bootstrap process yourself. Basically, you can let kubeadm do some parts and fill in yourself where you need customizations. Previously, you could only use kubeadm init to perform “the full meal deal.” The inclusion of the kubeadm alpha phase command supports our aim to make kubeadm more modular, letting you invoke atomic sub-steps of the bootstrap process.In v1.8.0, kubeadm alpha phase is just that: an alpha preview. We hope that we can graduate the command to beta as kubeadm phase in v1.9.0. We can’t wait for feedback from the community on how to better improve this feature!ImprovementsAlong with our new kubeadm features, we’ve also made improvements to existing ones. The Bootstrap Token feature that makes `kubeadm join` so short and sweet has graduated from alpha to beta and gained even more security features.If you made customizations to your system in v1.6 or v1.7, you had to remember what those customizations were when you upgraded your cluster. No longer: beginning with v1.8.0, kubeadm uploads your configuration to a ConfigMap inside of the cluster, and later reads that configuration when upgrading for a seamless user experience.The first certificate rotation feature has graduated to beta in v1.8, which is great to see. Thanks to the Auth Special Interest Group, the Kubernetes node component kubelet can now rotate its client certificate automatically. We expect this area to improve continuously, and will continue to be a part of this cross-SIG effort to easily rotate all certificates in any cluster.Last but not least, kubeadm is more resilient now. kubeadm init will detect even more faulty environments earlier, and time out instead of waiting forever for the expected condition.The scope of kubeadmAs there are so many different end-to-end installers for Kubernetes, there is some fragmentation in the ecosystem. With each new release of Kubernetes, these installers naturally become more divergent. This can create problems down the line if users rely on installer-specific variations and hooks that aren’t standardized in any way. Our goal from the beginning has been to make kubeadm a building block for deploying Kubernetes clusters and to provide kubeadm init and kubeadm join as best-practice “fast paths” for new Kubernetes users. Ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.kubeadm performs the actions necessary to get a minimum viable cluster up and running. It only cares about bootstrapping, not about provisioning machines, by design. Likewise, installing various nice-to-have addons by default like the Kubernetes Dashboard, some monitoring solution, cloud provider-specific addons, etc. is not in scope. Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, that installs the software the end user needs.v1.9.0 and beyondWhat’s in store for the future of kubeadm?Planned featuresWe plan to address high availability (replicated etcd and multiple, redundant API servers and other control plane components) as an alpha feature in v1.9.0. This has been a regular request from our user base.Also, we want to make self-hosting the default way to deploy your control plane: Kubernetes becomes much easier to manage if we can rely on Kubernetes’ own tools to manage the cluster components.Promoting kubeadm adoption and getting involvedThe kubeadm adoption working group is an ongoing effort between SIG Cluster Lifecycle and other parties in the Kubernetes ecosystem. This working group focuses on making kubeadm more extensible in order to promote adoption of it for other end-to-end installers in the community. Everyone is welcome to join. So far, we’re glad to announce that kubespray started using kubeadm under the hood, and gained new features at the same time! We’re excited to see others follow and make the ecosystem stronger.kubeadm is a great way to learn about Kubernetes: it binds all of Kubernetes’ components together in a single package. To learn more about what kubeadm really does under the hood, this document describes kubeadm functions in v1.8.0.If you want to get involved in these efforts, join SIG Cluster Lifecycle. We meet on Zoom once a week on Tuesdays at 16:00 UTC. For more information about what we talk about in our weekly meetings, check out our meeting notes. Meetings are a great educational opportunity, even if you don’t want to jump in and present your own ideas right away. You can also sign up for our mailing list, join our Slack channel, or check out the video archive of our past meetings. Even if you’re only interested in watching the video calls initially, we’re excited to welcome you as a new member to SIG Cluster Lifecycle!If you want to know what a kubeadm developer does at a given time in the Kubernetes release cycle, check out this doc. Finally, don’t hesitate to join if any of our upcoming projects are of interest to you!Thank you,Lucas KäldströmKubernetes maintainer & SIG Cluster Lifecycle co-leadWeaveworks contractor
Quelle: kubernetes

Five Days of Kubernetes 1.8

Kubernetes 1.8 is live, made possible by hundreds of contributors pushing thousands of commits in this latest releases.The community has tallied more than 66,000 commits in the main repo and continues rapid growth outside of the main repo, which signals growing maturity and stability for the project. The community has logged more than 120,000 commits across all repos and 17,839 commits across all repos for v1.7.0 to v1.8.0 alone.With the help of our growing community of 1,400 plus contributors, we issued more than 3,000 PRs and pushed more than 5,000 commits to deliver Kubernetes 1.8 with significant security and workload support updates. This all points to increased stability, a result of our project-wide focus on maturing process, formalizing architecture, and strengthening Kubernetes’ governance model.While many improvements have been contributed, we highlight key features in this series of in-depth posts listed below. Follow along and see what’s new and improved with storage, security and more.Day 1: 5 Days of Kubernetes 1.8Day 2: kubeadm v1.8 Introduces Easy Upgrades for Kubernetes ClustersDay 3: Kuberentes v.1.8 Retrospective: It Takes a Village to Raise a KubernetesDay 4: Using RBAC, Generally Available in Kubernetes v1.8Day 5: Enforcing Network Policies in KubernetesConnectPost questions (or answer questions) on Stack Overflow Join the community portal for advocates on K8sPort Follow us on Twitter @Kubernetesio for latest updates Connect with the community on Slack Get involved with the Kubernetes project on GitHub
Quelle: kubernetes

What is Notary and why is it important to CNCF?

As you may have heard, the Notary project has been invited to join the Cloud Native Computing Foundation (CNCF). Much like its real world namesake, Notary is a platform for establishing trust over pieces of content.
In life, certain important events such as buying a house are facilitated by a trusted third party called a “notary.” When buying a house, this person is typically employed by the lender to verify your identity and serve as a witness to your signatures on the mortgage agreement. The notary carries a special stamp and will also sign the documents as an affirmation that a notary was present and verified all the required information relating to the borrowers.
In a similar manner, the Notary project, initially sponsored by Docker, is designed to provide high levels of trust  over digital content using strong cryptographic signatures. In addition to ensuring the provenance of the software, it also provides guarantees that the content is not modified without approval of the author anywhere in the supply chain.  This then allows higher level systems like Docker Enterprise Edition (EE)  with Docker Content Trust (which uses Notary) to establish clear policy on the usage of content.  For instance, a policy can be set that only signed content can be used at runtime and deployed by the orchestrators in the Docker platform. Overall Notary is a core piece of plumbing in Docker’s  approach to the secure supply chain whereby security is seamlessly and uniformly embedded into a workflow from development all the way through to operations.
Notary is an implementation of The Update Framework (TUF) written in Go. TUF was developed at the NYU Tandon School of Engineering. TUF was submitted to join CNCF in partnership with Notary. The combined nature of these two projects makes for a particularly compelling donation– both the specification and most widely deployed implementation are coming in together under the auspices of the CNCF.
With technologies such as containerd and Kubernetes already members of CNCF, Notary and TUF are the first security-related projects to be added to the CNFC. This year has seen a significant uptick in data security compromises and we believe the CNCF is positioning itself ahead of the curve by inviting Notary and TUF to join. We hope that more security-focused projects are added to the CNCF over time.
Notary is already used in production environments beyond container distribution with Cloudflare integrating it into their PAL tool for container identity bootstrapping and Kolide using it to secure their autoupdater for the osquery tool. If current trends continue, there will be many more users in search of tools to secure their software distribution channels in the near future and Notary, TUF, and the CNCF will be well positioned to meet that need.
 

What is #Notary and why is it important to @CloudNativeFdn ? @moby #securityClick To Tweet

The post What is Notary and why is it important to CNCF? appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/